Re: tableam scan-API patch broke foreign key validation

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: tableam scan-API patch broke foreign key validation
Дата
Msg-id 20190406182258.pvk5zkqdc6dobfg7@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: tableam scan-API patch broke foreign key validation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: tableam scan-API patch broke foreign key validation  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-04-06 14:13:29 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On April 6, 2019 11:07:55 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I plan to go ahead and commit Hadi's fix with that change included
> >> (as below), but I wonder whether anything else needs to be revisited.
> 
> > I posted pretty much that patch nearby, with some other questions. Was waiting for David to respond.... Let me dig
thatout.
 

The relevant thread is:
https://www.postgresql.org/message-id/20190325180405.jytoehuzkeozggxx%40alap3.anarazel.de


> Ah.  Would you rather I wait till you push yours?

Yours looks good to me, so go ahead. I think we need a bit more than
that, but that can easily be committed separately:

Wonder if you have an opinion on:

> I've also noticed that we should free the tuple - that doesn't matter
> for heap, but it sure does for other callers.  But uh, is it actually ok
> to validate an entire table's worth of foreign keys without a memory
> context reset? I.e. shouldn't we have a memory context that we reset
> after each iteration?
> 
> Also, why's there no CHECK_FOR_INTERRUPTS()? heap has some internally on
> a page level, but that doesn't seem all that granular?


Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tableam scan-API patch broke foreign key validation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: tableam scan-API patch broke foreign key validation