Re: The documentation for READ COMMITTED may be incomplete or wrong
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>,
Amit Langote <amitlangote09@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-05-18T22:26:22Z
Lists: pgsql-hackers
Attachments
- v1-fix-EPQ-HEAD-only.patch (text/x-diff) patch v1
Nathan Bossart <nathandbossart@gmail.com> writes: > On Thu, May 18, 2023 at 04:03:36PM -0400, Tom Lane wrote: >> What we need to do, I think, is set epqstate->relsubs_done[] for >> all target relations except the one we are stuffing a tuple into. > This seems generally reasonable to me. Here's a draft patch for this. I think it's OK for HEAD, but we are going to need some different details for the back branches, because adding a field to struct EPQState would create an ABI break. Our standard trick of shoving the field to the end in the back branches won't help, because struct EPQState is actually embedded in struct ModifyTableState, meaning that all the subsequent fields therein will move. Maybe we can get away with that, but I bet not. I think what the back branches will have to do is reinitialize the relsubs_done array every time through EvalPlanQual(), which is a bit sad but probably doesn't amount to anything compared to the startup overhead of the sub-executor. Debian Code Search doesn't know of any outside code touching relsubs_done, so I think we are safe in dropping that code in ExecScanReScan. It seems quite pointless anyway considering that up to now, EvalPlanQualBegin has always zeroed the whole array. regards, tom lane
Commits
-
Fix misbehavior of EvalPlanQual checks with multiple result relations.
- 70b42f279029 16.0 landed
- ff77d8687fa3 12.16 landed
- f8320cc72ddb 14.9 landed
- 956c6256a98e 13.12 landed
- 4729d1e8aab9 15.4 landed
-
Rework planning and execution of UPDATE and DELETE.
- 86dc90056dfd 14.0 cited