OK, I see at least one of the problems here.
UPDATE/DELETE with an Append plan have never worked --- not in recent
memory anyway --- because execMain's InitPlan() creates a result
RelationInfo that EndPlan() is expecting to close. But if the top plan
node is an Append then nodeAppend.c scribbles on
estate->es_result_relation_info. This leaves the originally created
RelationInfo unreachable ... which is bad enough, since that means a
leaked rel refcount, but there's worse to come. nodeAppend.c creates
its own set of RelationInfo nodes for the relation(s) it will scan.
At query end, it's left estate->es_result_relation_info pointing at a
random one of these. nodeAppend.c closes *and deletes* all its
RelationInfos. Now estate->es_result_relation_info is pointing at a
closed-and-deleted RelationInfo that EndPlan() will then try to close
I believe the correct fix is
(a) ExecInitAppend() must incorporate the RelationInfo already
created by InitPlan() into its list of RelationInfos, rather
than creating a second RelationInfo (= extra relcache refcount)
for that relation.
(b) ExecEndAppend() must reset estate->es_result_relation_info to
NULL, so it won't be left pointing to a deleted RelationInfo.
(c) EndPlan() must not examine estate->es_result_relation_info until
after it has called the node-type-specific end routine; otherwise
change (b) will not be able to prevent EndPlan() from doing the
On it now...
regards, tom lane
In response to
pgsql-patches by date
|Next:||From: Denis Perchine||Date: 2000-06-10 23:12:34|
|Subject: Fwd: Patch for 'Not to stuff everything as files in a single directory, hash dirs'|
|Previous:||From: Bruce Momjian||Date: 2000-06-10 01:26:07|
|Subject: Re: Re: [CORE] Re: MY PATCH|