Re: Recent 027_streaming_regress.pl hangs - Mailing list pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:
> We'll see. I have switched crake from --run-parallel mode to --run-all 
> mode i.e. the runs are serialized. Maybe that will be enough to stop the 
> errors. I'm still annoyed that this test is susceptible to load, if that 
> is indeed what is the issue.

crake is still timing out intermittently on 027_streaming_regress.pl,
so that wasn't it.  I think we need more data.  We know that the
wait_for_catchup query is never getting to true:

    SELECT '$target_lsn' <= ${mode}_lsn AND state = 'streaming'

but we don't know if the LSN condition or the state condition is
what is failing.  And if it is the LSN condition, it'd be good
to see the actual last LSN, so we can look for patterns like
whether there is a page boundary crossing involved.  So I suggest
adding something like the attached.

If we do this, I'd be inclined to instrument wait_for_slot_catchup
and wait_for_subscription_sync similarly, but I thought I'd check
for contrary opinions first.

            regards, tom lane

diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index 32ee98aebc..3403626f92 100644
--- a/src/test/perl/PostgreSQL/Test/Cluster.pm
+++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
@@ -2948,6 +2948,13 @@ sub wait_for_catchup
         }
         else
         {
+            # Fetch additional detail for debugging purposes
+            $query = qq[SELECT application_name, ${mode}_lsn, state
+                        FROM pg_catalog.pg_stat_replication
+                        WHERE application_name IN ('$standby_name', 'walreceiver')];
+            my $details = $self->safe_psql('postgres', $query);
+            diag qq(Last application_name|${mode}_lsn|state:
+${details});
             croak "timed out waiting for catchup";
         }
     }