Re: Recent 027_streaming_regress.pl hangs
От | Andrew Dunstan |
---|---|
Тема | Re: Recent 027_streaming_regress.pl hangs |
Дата | |
Msg-id | 4230d49c-898d-43e0-8ca9-a64b5b702b1d@dunslane.net обсуждение исходный текст |
Ответ на | Re: Recent 027_streaming_regress.pl hangs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Recent 027_streaming_regress.pl hangs
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: