Re: Recent 027_streaming_regress.pl hangs
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alexander Lakhin <exclusion@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>,
Michael Paquier <michael@paquier.xyz>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>,
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: 2024-08-12T00:32:05Z
Lists: pgsql-hackers
Attachments
- instrument-wait_for_catchup-timeouts.patch (text/x-diff) patch
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
Commits
-
Log more info when wait-for-catchup tests time out.
- e57296ed4867 17.0 landed
- 2aecbd752616 18.0 landed
-
Add a new slot sync worker to synchronize logical slots.
- 93db6cbda037 17.0 cited