Re: tableam scan-API patch broke foreign key validation
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Hadi Moshayedi <hadi@moshayedi.net>
Date: 2019-04-06T18:22:58Z
Lists: 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 that out. 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
Commits
-
Clean up side-effects of commits ab5fcf2b0 et al.
- 10e3991fad8a 11.3 cited
-
Fix failures in validateForeignKeyConstraint's slow path.
- c2a5fb33d104 11.3 landed
- 46e3442c9ec8 12.0 landed