Marko Tiikkaja wrote:
> Hi hackers,
>
> Any chance to get this fixed in time for 9.1.16?
I hope you had pinged some days earlier. Here's a patch, but I will
wait until this week's releases have been tagged before pushing.
I checked 9.2, and it doesn't look like it's subject to the same
problem: instead of HeapTupleSatisfiesVacuum, it uses
HeapTupleIsSurelyDead in the equivalent place. Still, I think it's
saner to apply the same bug because as Andres notes the problem might
still be present in pgrowlocks and who knows what else.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 476c53d..b90c110 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -383,6 +383,21 @@ MultiXactIdIsRunning(MultiXactId multi)
debug_elog3(DEBUG2, "IsRunning %u?", multi);
+ /*
+ * During recovery, all multixacts can be considered not running: in
+ * effect, tuple locks are not held in standby servers, which is fine
+ * because the standby cannot acquire further tuple locks nor update/delete
+ * tuples.
+ *
+ * We need to do this first, because GetMultiXactIdMembers complains if
+ * called on recovery.
+ */
+ if (RecoveryInProgress())
+ {
+ debug_elog2(DEBUG2, "IsRunning: in recovery");
+ return false;
+ }
+
nmembers = GetMultiXactIdMembers(multi, &members);
if (nmembers < 0)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
