From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
Date: Wed, 09 Jun 2021 15:07:48 -0400
Message-ID: <1428037.1623265668@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, y.sokolov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Add PortalDrop in exec_execute_message
In-Reply-To: <1428037.1623265668@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox