Skip site navigation (1) Skip section navigation (2)

Re: Re: [CORE] Re: MY PATCH

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Bitmead <chris(at)bitmead(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-core(at)postgresql(dot)org, "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Re: [CORE] Re: MY PATCH
Date: 2000-06-10 02:02:45
Message-ID: 21424.960602565@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
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
again.  Oops.

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
      wrong thing.

On it now...

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Denis PerchineDate: 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 MomjianDate: 2000-06-10 01:26:07
Subject: Re: Re: [CORE] Re: MY PATCH

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group