Re: Stabilize and shorten test_checksums/013_rewind test

From: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Subject: Re: Stabilize and shorten test_checksums/013_rewind test
Date: 2026-09-18 13:47:10
Message-ID: CAN55FZ1-uY=17YQ1+=ahcaTAwv04rt=D8DPx2tKouzRpopFffQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thank you for looking into this!

On Fri, 18 Sept 2026 at 15:51, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 18 Sep 2026, at 12:26, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:
> > Problem #1:
> >
> > We wait for the primary's insert LSN in three places, but the primary
> > might be idle and not have sent it yet:
>
> Makes sense.
>
> -$node_a->wait_for_catchup($node_b, 'replay', $node_a->lsn('insert'));
> +# Backup completion has flushed the required WAL.
> +$node_a->wait_for_catchup($node_b, 'replay', $node_a->lsn('flush'));
>
> In these cases, couldn't we just wait for the replay LSN, ie the default for
> wait_for_catchup?

Sorry, I am a bit confused. AFAIU, you meant:

$node_a->wait_for_catchup($node_b);

which is

$node_a->wait_for_catchup($node_b, 'replay', $node_a->lsn('write'));

If that is the case, could we still need to wait for an additional
primary-side flush, since written WAL might not have been flushed yet?
I understand that this might not cause the same long delay as waiting
for the insert LSN. On my local, ->lsn('write') and ->lsn('flush') are
basically same, they both take ~3 seconds.

My idea was that since the WAL needed by the tests has already been
flushed, I thought that would be enough for the tests. Also, is using
->lsn('write') considered better for these cases or do you recommend
it because of the simplicity?

--
Regards,
Nazir Bilal Yavuz
Microsoft

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-09-18 14:11:20 Re: Add ASCII fast path to Unicode normalization functions
Previous Message Antonin Houska 2026-09-18 13:16:32 Re: Race conditions in logical decoding