Re: BUG #18830: ExecInitMerge Segfault on MERGE
Tender Wang <tndrwang@gmail.com>
From: Tender Wang <tndrwang@gmail.com>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
David Rowley <dgrowleyml@gmail.com>, pgsql-bugs@lists.postgresql.org, tharakan@gmail.com
Date: 2025-03-13T07:29:35Z
Lists: pgsql-bugs
Dean Rasheed <dean.a.rasheed@gmail.com> 于2025年3月13日周四 03:23写道: > On Wed, 12 Mar 2025 at 16:11, Tender Wang <tndrwang@gmail.com> wrote: > > > > I can find another same error in the below query: > > > > with t as (update part_abc set c = true where a = stable_one() +2 > returning a) insert into foo select a from t; > > > > Interesting example. That passes in HEAD, but fails with the v1 patch > because it is attempting to open a pruned result relation when it > doesn't need to. > > Attached is a rough patch that attempts to solve these issues locally > in ExecInitModifyTable(), by not allowing all result relations to be > pruned for that node. That makes it easy to handle cases with multiple > ModifyTable nodes. > > This also has the advantage that all these relations can continue to > be pruned from the subplans of the ModifyTable nodes, making those > scans more efficient, and it only keeps a pruned result relation if > all other result relations have been pruned. > > It does mean that ExecGetRangeTableRelation() needs to allow pruned > relations to be opened, if called from ExecInitResultRelation(). I > think that's OK because the check for opening pruned relations still > applies to scan relations. > > I also adjusted explain.c slightly, to avoid the dummy pruned result > relation that we might now keep from appearing in the EXPLAIN output > as a target relation. Allowing it to be shown looked a bit odd, > because it's not really the target relation in any real sense. > > I also noticed a few Asserts in ExecInitModifyTable() that didn't > appear to be doing what they were originally intended to do. > I tested and debugged the attached patch. I didn't find any other issue. A comment in execPartition.h may need to be changed: * partrel Partitioned table Relation; obtained by * ExecGetRangeTableRelation(estate, rti), where Because the func interface has changed, the above comments are better to be changed "ExecGetRangeTableRelation(estate, rti, false)". -- Thanks, Tender Wang
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Ensure first ModifyTable rel initialized if all are pruned
- 28317de723b6 18.0 landed
-
Don't lock partitions pruned by initial pruning
- 525392d5727f 18.0 cited
-
Fix an oversight in cbc127917 to handle MERGE correctly
- 75dfde13639a 18.0 cited
-
Remove some unnecessary fields from Plan trees.
- 52ed730d511b 12.0 cited