pgsql: Shut down EvalPlanQual machinery when LockRows node reaches the - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Shut down EvalPlanQual machinery when LockRows node reaches the
Date
Msg-id E1lrMOw-0005ET-PE@gemulon.postgresql.org
Whole thread Raw
List 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(+)


pgsql-committers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
Next
From: Tom Lane
Date:
Subject: pgsql: Rearrange logrep worker's snapshot handling some more.