Hi, hackers.
I've been playing with "autoprepared" patch, and have got isolation
"freeze-the-dead" test stuck on first VACUUM FREEZE statement.
After some research I found issue is reproduced with unmodified master
branch if extended protocol used. I've prepared ruby script for
demonstration (cause ruby-pg has simple interface to PQsendQueryParams).
Further investigation showed it happens due to portal is not dropped
inside of exec_execute_message, and it is kept in third session till
COMMIT is called. Therefore heap page remains pinned, and VACUUM FREEZE
became locked inside LockBufferForCleanup.
It seems that it is usually invisible to common users since either:
- command is called as standalone and then transaction is closed
immediately,
- next PQsendQueryParams will initiate another unnamed portal using
CreatePortal("", true, true) and this action will drop previous
one.
But "freeze-the-dead" remains locked since third session could not
send COMMIT until VACUUM FULL finished.
I propose to add PortalDrop at the 'if (completed)' branch of
exec_execute_message.
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -2209,6 +2209,8 @@ exec_execute_message(const char *portal_name, long
max_rows)
if (completed)
{
+ PortalDrop(portal, false);
+
if (is_xact_command)
{
With this change 'make check-world' runs without flaws (at least
on empty configure with enable-cassert and enable-tap-tests).
There is small chance applications exist which abuses seekable
portals with 'execute' protocol message so not every completed
portal can be safely dropped. But I believe there is some sane
conditions that cover common case. For example, isn't empty name
check is enough? Can client reset or seek portal with empty
name?
regards,
Sokolov Yura aka funny_falcon
