pgsql: Shut down EvalPlanQual machinery when LockRows node reaches the

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Shut down EvalPlanQual machinery when LockRows node reaches the
Date: 2021-06-10 15:15:22
Message-ID: E1lrMOw-0005ET-PE@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Shut down EvalPlanQual machinery when LockRows node reaches the end.

Previously, we left the EPQ sub-executor alone until ExecEndLockRows.
This caused any buffer pins or other resources that it might hold to
remain held until ExecutorEnd, which in some code paths means that
they are held till the Portal is closed. That can cause user-visible
problems, such as blocking VACUUM; and it's unlike the behavior of
ordinary table-scanning nodes, which will have released all buffer
pins by the time they return an EOF indication.

We can make LockRows work more like other plan nodes by calling
EvalPlanQualEnd just before returning NULL. We still need to call it
in ExecEndLockRows in case the node was not run to completion, but in
the normal case the second call does nothing and costs little.

Per report from Yura Sokolov. In principle this is a longstanding
bug, but in view of the lack of other complaints and the low severity
of the consequences, I chose not to back-patch.

Discussion: https://postgr.es/m/4aa370cb91ecf2f9885d98b80ad1109c@postgrespro.ru

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/bb4aed46a5aeb00d2f1d8b8160feed339f4eaf12

Modified Files
--------------
src/backend/executor/nodeLockRows.c | 5 +++++
1 file changed, 5 insertions(+)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2021-06-10 16:27:43 pgsql: Rearrange logrep worker's snapshot handling some more.
Previous Message Robert Haas 2021-06-10 14:54:52 Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode