Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Дата
Msg-id CA+HiwqEvB-JELhjPgwFNDq2hPEfTFUjUOsvJyf0S50vOLm2mAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
Hi Dilip,

On Wed, Jul 10, 2019 at 1:29 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Wed, Jul 10, 2019 at 9:44 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > On Fri, Nov 2, 2018 at 1:34 PM Amit Langote wrote:
> > > Okay, here are two patches:
> > >
> > > 0001 adds a new RelOptInfo member inh_root_parent that's set for
> > > inheritance child otherrels and contains the RT index of the inheritance
> > > parent table mentioned in the query from which they originated.
> > >
> > > 0002 is your patch that modifies examine_variable, etc. to use the
> > > permissions granted on parent before reading stats on otherrel inheritance
> > > child tables. I've added your name as the author in the 2nd patch.
> > >
> >
> > I have looked into the patches and these look fine to me.  I have also
> > added it to the next commitfest.
> >
> Hi Amit,
>
> I have reviewed your 0001 patch and I think you have already taken a
> look on 0002.  So should I move it to "Ready for Committer" or you
> want to review it further?

Thanks for checking.  There has been a lot of churn in the inheritance
planning code since my last email on this thread, so I'd like to
reconsider.  I'm busy this week with some things, so I'll try posting
something on next Tuesday.

Thanks,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add parallelism and glibc dependent only options to reindexdb