On 2024-08-11 Su 8:32 PM, Tom Lane wrote:
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.
Seems reasonable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
