Date: Wed, 9 Jun 2021 15:34:53 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
Message-ID: <202106091934.f6m5kvqizrg4@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1428037.1623265668@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/202106091934.f6m5kvqizrg4%40alvherre.pgsql>
Precedence: bulk

On 2021-Jun-09, Tom Lane wrote:

> 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.)

Thanks for researching that -- good find.

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

Agreed.  I'll get it pushed after the patch I'm currently looking at.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W