MIME-Version: 1.0
References: 
 <CABPTF7WZ1yuYz8V=xsbghg8e7qaAm5MpyNw6BthWcbN7+P6biw@mail.gmail.com>
 <aeKqac6dHfCNoNxb@paquier.xyz>
 <CABPTF7VouG5DSvdgPSg1ko6ybHhNPQk5sxJQMiy8r_gr_bEtug@mail.gmail.com>
 <CAPpHfdvSgasQ3XeTAbA=cqH_BVY9pD6BVuXj+xEgyYGx2_nfEw@mail.gmail.com>
 <CAPpHfdu47tAB1s1q8s4Qy1wZ9jKTA46cjQGRTugMb_5mze8fbQ@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdu47tAB1s1q8s4Qy1wZ9jKTA46cjQGRTugMb_5mze8fbQ@mail.gmail.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Mon, 20 Apr 2026 21:54:16 +0800
Message-ID: 
 <CABPTF7UNdY_dSqTzEvXOLkQa8Fr3-j-VTyQGEgMhnwfzNuu0Fg@mail.gmail.com>
Subject: Re: test: avoid redundant standby catchup in 049_wait_for_lsn
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABPTF7UNdY_dSqTzEvXOLkQa8Fr3-j-VTyQGEgMhnwfzNuu0Fg%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 20, 2026 at 6:21=E2=80=AFPM Alexander Korotkov <aekorotkov@gmai=
l.com> wrote:
>
> On Sat, Apr 18, 2026 at 10:58=E2=80=AFAM Alexander Korotkov
> <aekorotkov@gmail.com> wrote:
> > On Sat, Apr 18, 2026 at 7:20=E2=80=AFAM Xuneng Zhou <xunengzhou@gmail.c=
om> wrote:
> > >> On Fri, Apr 17, 2026 at 08:25:35PM +0800, Xuneng Zhou wrote:
> > >> > The change preserves the same coverage while removing one redundan=
t
> > >> > replay catch-up on the delayed standby. It appears to reduce the t=
est
> > >> > 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.  Th=
e
> > >> test is clearly written so as we want two wait checks to happen, for
> > >> for CREATE FUNCTION, and one for CREATE PROCEDURE.  Removing the fir=
st
> > >> 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 dist=
inct purposes and are not redundant. The main motivation for this patch was=
 efficiency. In my testing, the new test added approximately 7 seconds to t=
he runtime, while the creation of the procedure and function completed quic=
kly. I suspect the latency stems from the wait-for-catch-up step. When I re=
moved it, the test runtime dropped by about 7 seconds.I haven't yet investi=
gated why the wait is so costly in this case. I should probably look into t=
hat before proposing this change.
> >
> > On my laptop the time needed to run t/049_wait_for_lsn.pl also drops
> > from 20 secs to 12 secs.  The influence to the runtime of the whole
> > test suite in parallel would be not that big as CPU time only drops
> > from 2.16 sec to 2.07 sec.  But anyway that's pretty significant.
> > I've revised comment message a bit and surrounding comments.  I'm
> > going to push this if no objections.
>
> Pushed.
>

Thanks for pushing it. I haven't had time to investigate the latency
yet, but will do it later.

Best,
Xuneng