Re: test: avoid redundant standby catchup in 049_wait_for_lsn

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Re: test: avoid redundant standby catchup in 049_wait_for_lsn
Date: 2026-04-18 04:19:50
Message-ID: CABPTF7VouG5DSvdgPSg1ko6ybHhNPQk5sxJQMiy8r_gr_bEtug@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Michael,

On Fri, Apr 17, 2026 at 08:25:35PM +0800, Xuneng Zhou wrote:
> > The change preserves the same coverage while removing one redundant
> > replay catch-up on the delayed standby. It appears to reduce the test
> > runtime by about 7 seconds, though I have looked into why much of the
> > improvement comes from this change alone.
>
> Alexander may think differently and remove that, but I disagree. The
> test is clearly written so as we want two wait checks to happen, for
> for CREATE FUNCTION, and one for CREATE PROCEDURE. Removing the first
> check to keep only the second one removes its meaning. In short, I
> see nothing wrong to deal with here.
>

Thank you for the review. I agree that the two wait checks serve distinct
purposes and are not redundant. The main motivation for this patch was
efficiency. In my testing, the new test added approximately 7 seconds to
the runtime, while the creation of the procedure and function completed
quickly. I suspect the latency stems from the wait-for-catch-up step. When
I removed it, the test runtime dropped by about 7 seconds.I haven't yet
investigated why the wait is so costly in this case. I should probably look
into that before proposing this change.

Best,
Xuneng

>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-04-18 07:49:57 Re: Add bms_offset_members() function for bitshifting Bitmapsets
Previous Message Haibo Yan 2026-04-18 04:02:36 Re: Implement missing join selectivity estimation for range types