See also
afdeff10526. Failures after that commit provided a few more hints,
but not yet enough to understand what's going on.
In 019_replslot_limit.pl shut down nodes with fast instead of immediate mode
if we observe the failure mode. That should tell us whether the failures we're
observing are just a timing issue under high load. PGCTLTIMEOUT should prevent
buildfarm animals from hanging endlessly.
Also adds a bit more logging to replication slot drop and ShutdownPostgres().
Discussion: https://postgr.es/m/
20220225192941.hqnvefgdzaro6gzg@alap3.anarazel.de
if (!s->in_use)
continue;
+ /* unlocked read of active_pid is ok for debugging purposes */
+ elog(DEBUG3, "temporary replication slot cleanup: %d in use, active_pid: %d",
+ i, s->active_pid);
+
SpinLockAcquire(&s->mutex);
if (s->active_pid == MyProcPid)
{
char path[MAXPGPATH];
char tmppath[MAXPGPATH];
+ /* temp debugging aid to analyze 019_replslot_limit failures */
+ elog(DEBUG3, "replication slot drop: %s: begin", NameStr(slot->data.name));
+
/*
* If some other backend ran this code concurrently with us, we might try
* to delete a slot with a certain name while someone else was trying to
path, tmppath)));
}
+ elog(DEBUG3, "replication slot drop: %s: removed on-disk",
+ NameStr(slot->data.name));
+
/*
* The slot is definitely gone. Lock out concurrent scans of the array
* long enough to kill it. It's OK to clear the active PID here without
* a slot while we're still cleaning up the detritus of the old one.
*/
LWLockRelease(ReplicationSlotAllocationLock);
+
+ elog(DEBUG3, "replication slot drop: %s: done",
+ NameStr(slot->data.name));
}
/*
}
return false;
}
+
+/* temp debugging aid to analyze 019_replslot_limit failures */
+int
+LWLockHeldCount(void)
+{
+ return num_held_lwlocks;
+}
* them explicitly.
*/
LockReleaseAll(USER_LOCKMETHOD, true);
+
+ /*
+ * temp debugging aid to analyze 019_replslot_limit failures
+ *
+ * If an error were thrown outside of a transaction nothing up to now
+ * would have released lwlocks. We probably will add an
+ * LWLockReleaseAll(). But for now make it easier to understand such cases
+ * by warning if any lwlocks are held.
+ */
+#ifdef USE_ASSERT_CHECKING
+ {
+ int held_lwlocks = LWLockHeldCount();
+ if (held_lwlocks)
+ elog(WARNING, "holding %d lwlocks at the end of ShutdownPostgres()",
+ held_lwlocks);
+ }
+#endif
}
extern void LWLockReleaseAll(void);
extern bool LWLockHeldByMe(LWLock *lock);
extern bool LWLockHeldByMeInMode(LWLock *lock, LWLockMode mode);
+extern int LWLockHeldCount(void);
extern bool LWLockWaitForVar(LWLock *lock, uint64 *valptr, uint64 oldval, uint64 *newval);
extern void LWLockUpdateVar(LWLock *lock, uint64 *valptr, uint64 value);
$node_primary3->wait_for_catchup($node_standby3);
my $senderpid = $node_primary3->safe_psql('postgres',
"SELECT pid FROM pg_stat_activity WHERE backend_type = 'walsender'");
-like($senderpid, qr/^[0-9]+$/, "have walsender pid $senderpid");
+
+# We've seen occasional cases where multiple walsender pids are active. An
+# immediate shutdown may hide evidence of a locking bug. So if multiple
+# walsenders are observed, shut down in fast mode, and collect some more
+# information.
+if (not like($senderpid, qr/^[0-9]+$/, "have walsender pid $senderpid"))
+{
+ my ($stdout, $stderr);
+ $node_primary3->psql('postgres',
+ "\\a\\t\nSELECT * FROM pg_stat_activity",
+ stdout => \$stdout, stderr => \$stderr);
+ diag $stdout, $stderr;
+ $node_primary3->stop('fast');
+ $node_standby3->stop('fast');
+ die "could not determine walsender pid, can't continue";
+}
+
my $receiverpid = $node_standby3->safe_psql('postgres',
"SELECT pid FROM pg_stat_activity WHERE backend_type = 'walreceiver'");
like($receiverpid, qr/^[0-9]+$/, "have walreceiver pid $receiverpid");