Re: pg_receivewal starting position - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: pg_receivewal starting position
Date
Msg-id 20211027.111728.1991417859896017411.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: pg_receivewal starting position  (Ronan Dunklau <ronan.dunklau@aiven.io>)
Responses Re: pg_receivewal starting position  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Re: pg_receivewal starting position  (Ronan Dunklau <ronan.dunklau@aiven.io>)
List pgsql-hackers
At Tue, 26 Oct 2021 11:01:46 +0200, Ronan Dunklau <ronan.dunklau@aiven.io> wrote in
> Le mardi 26 octobre 2021, 08:27:47 CEST Ronan Dunklau a écrit :
> > Yes, I will try to simplify the logic of the patch I sent last week. I'll
> > keep you posted here soon.
>
> I was able to simplify it quite a bit, by using only one standby for both test
> scenarios.
>
> This test case verify that after a timeline switch, if we resume from a
> previous state we will archive:
>  - segments from the old timeline
>  - segments from the new timeline
>  - the timeline history file itself.
>
> I chose to check against a full segment from the previous timeline, but it
> would have been possible to check that the latest timeline segment was
> partial. I chose not not, in the unlikely event we promote at an exact segment
> boundary. I don't think it matters much, since partial wal files are already
> covered by other tests.

+my @walfiles = glob "$slot_dir/*";

This is not used.

Each pg_receivewal run stalls for about 10 or more seconds before
finishing, which is not great from the standpoint of recently
increasing test run time.

Maybe we want to advance LSN a bit, after taking $nextlsn then pass
"-s 1" to pg_receivewal.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: pgsql: Remove unused wait events.
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: pg_receivewal starting position