Andres Freund <andres@anarazel.de> writes:
> The relevant thread is:
> https://www.postgresql.org/message-id/20190325180405.jytoehuzkeozggxx%40alap3.anarazel.de
Yeah, I just found that --- would have seen it sooner if David had
not elected to make it a new thread.
> 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.
Why should this code need to free anything? That'd be the responsibility
of the slot code, no?
>> 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?
These are good questions. Just eyeing RI_FKey_check(), I think
that it might not have any significant leaks because most of the work
is done in an SPI context, but obviously that's pretty fragile.
The memory-context stuff in your WIP patch seems wrong, btw;
the second or later iteration of the loop would trash oldcxt.
But clearly we need a test case here. I'll adjust Hadi's example
so that there's more than one tuple to check, and push it.
regards, tom lane