Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
От | Tom Lane |
---|---|
Тема | Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof? |
Дата | |
Msg-id | 11560.1531349520@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CVE-2017-7484-induced bugs, or, btree cmp functions are notleakproof?
|
Список | pgsql-hackers |
I wrote: > I propose to run through the system operator classes, find any for which > the comparison function isn't marked leakproof but the operators are, > and fix them. This is clearly appropriate for HEAD and maybe it's not > too late to force an initdb for v11 --- thoughts? I did that for the built-in btree opclasses. I decided that it's probably not worth forcing an initdb in v11 for, though. In principle, losing selectivity estimates because of non-leakproof functions should only happen in queries that are going to fail at runtime anyway. The real problem that ought to be addressed and perhaps back-patched is this: > Another question that could be raised is why we are refusing to use > stats for a child table when the caller has select on the parent. > It's completely trivial to extract data from a child table if you > have select on the parent, so it seems like we are checking the > wrong table's privileges. regards, tom lane
В списке pgsql-hackers по дате отправления: