Re: Add PortalDrop in exec_execute_message
Tom Lane <tgl@sss.pgh.pa.us>
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
Date: 2021-06-09T17:25:59Z
Lists: pgsql-hackers
Attachments
- shut-down-EPQ-when-LockRows-stops.patch (text/x-diff) patch
I wrote: > I'm still wondering though why Yura is observing resources remaining > held by an executed-to-completion Portal. I think investigating that > might be more useful than tinkering with pipeline mode. I got a chance to look into this finally. The lens I've been looking at this through is "why are we still holding any buffer pins when ExecutorRun finishes?". Normal table scan nodes won't do that. 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.) regards, tom lane
Commits
-
Add 'Portal Close' message to pipelined PQsendQuery()
- 4efcf47053ea 14.0 landed
-
Shut down EvalPlanQual machinery when LockRows node reaches the end.
- bb4aed46a5ae 14.0 landed
-
Update libpq to make new features of FE/BE protocol available to
- efc3a25bb02a 7.4.1 cited
-
Extended query protocol: parse, bind, execute, describe FE/BE messages.
- 16503e6fa4a1 7.4.1 cited