Re: Implement waiting for wal lsn replay: reloaded - Mailing list pgsql-hackers

From Xuneng Zhou
Subject Re: Implement waiting for wal lsn replay: reloaded
Date
Msg-id CABPTF7W0GGEpTeRS8YiMX=77DJbe9jqoUEaWpWHcxxs1xvWkkA@mail.gmail.com
Whole thread
In response to Re: Implement waiting for wal lsn replay: reloaded  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Implement waiting for wal lsn replay: reloaded
List pgsql-hackers
Hi Tom,

On Tue, Apr 7, 2026 at 10:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > I wondered why my buildfarm animals got noticeably slower today.
> > There seem to be a couple of culprits, but one of them is that
> > 7e8aeb9e4 (Use WAIT FOR LSN) has caused the runtime of pg_rewind's
> > t/003_extrafiles.pl to go through the roof.  On indri's host, that
> > TAP test took about 3 seconds immediately before that commit, and
> > about 45 seconds immediately after.
>
> I'm wrong: there's only one culprit.  The other big change in runtime
> today is that src/test/recovery's t/033_replay_tsp_drops.pl went from
> about 4 seconds to about 46, and that jump also happened at 7e8aeb9e4.
> So we still have a mystery, but it's "what do those two tests have in
> common that is shared by no others?".
>
>                         regards, tom lane

Thanks for reporting this. I think it could be related to the read of
not-yet-updated writtenUpto position.  I'll look into this and propose
a fix shortly.


--
Best,
Xuneng



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: test_autovacuum/001_parallel_autovacuum is broken
Next
From: Noah Misch
Date:
Subject: Re: Adding REPACK [concurrently]