From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Yura Sokolov <y.sokolov@postgrespro.ru>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
In-reply-to: <1422606.1623259559@sss.pgh.pa.us>
References: <202106072208.jeksdphlipvp@alvherre.pgsql>
 <1029215.1623104149@sss.pgh.pa.us> <1422606.1623259559@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 09 Jun 2021 13:25:59 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1428036.1623265668.1@sss.pgh.pa.us>
Date: Wed, 09 Jun 2021 15:07:48 -0400
Message-ID: <1428037.1623265668@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1428037.1623265668%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> It turns out that the problem is specific to SELECT FOR UPDATE, and
> it happens because nodeLockRows is not careful to shut down the
> EvalPlanQual mechanism it uses before returning NULL at the end of
> a scan.  If EPQ has been fired, it'll be holding a tuple slot
> referencing whatever tuple it was last asked about.  The attached
> trivial patch seems to take care of the issue nicely, while adding
> little if any overhead.  (A repeat call to EvalPlanQualEnd doesn't
> do much.)

BTW, to be clear: I think Alvaro's change is also necessary.
If libpq is going to silently do something different in pipeline
mode than it does in normal mode, it should strive to minimize
the semantic difference.  exec_simple_query includes a PortalDrop,
so we'd best do the same in pipeline mode.  But this LockRows
misbehavior would be visible in other operating modes anyway.

			regards, tom lane