Horton

Re: Recent 027_streaming_regress.pl hangs

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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-12T17:21:04Z
Lists: pgsql-hackers 
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2024-08-11 Su 8:32 PM, Tom Lane wrote:
>> 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.

> Seems reasonable.

Pushed.  In the event I made it just "SELECT * FROM" the relevant
view: there will be few if any rows that aren't potentially
interesting, and filtering the columns doesn't seem like a
forward-looking idea either.

			regards, tom lane

Commits

  1. Log more info when wait-for-catchup tests time out.

  2. Add a new slot sync worker to synchronize logical slots.