| From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
|---|---|
| To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: test: avoid redundant standby catchup in 049_wait_for_lsn |
| Date: | 2026-09-20 02:16:40 |
| Message-ID: | CABPTF7XTZFcXZvERtN74rNF5_NdcJoc2s52akVgtSpLF-0mL6A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Alexander,
On Mon, Apr 20, 2026 at 9:54 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> On Mon, Apr 20, 2026 at 6:21 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >
> > On Sat, Apr 18, 2026 at 10:58 AM Alexander Korotkov
> > <aekorotkov(at)gmail(dot)com> wrote:
> > > On Sat, Apr 18, 2026 at 7:20 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > > >> 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.
> > >
> > > 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.
While working on other things, I revisited the thread and looked into
the issue. The delayed investigation has exposed an unexpected
fragility. I'll post some findings soon.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Wei Sun | 2026-09-20 02:50:17 | Re: Severe performance degradation with concurrent updates due to excessive EvalPlanQual (EPQ) re‑evaluation |
| Previous Message | Tom Lane | 2026-09-20 02:12:12 | Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg |