Re: pg_receivewal starting position

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: ronan.dunklau@aiven.io
Cc: bharath.rupireddyforpostgres@gmail.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org, sawada.mshk@gmail.com
Date: 2021-10-27T02:17:28Z
Lists: 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



Commits

  1. Add TAP test for pg_receivewal with timeline switch

  2. Speed up TAP tests of pg_receivewal

  3. Allow pg_receivewal to stream from a slot's restart LSN

  4. Add replication command READ_REPLICATION_SLOT

  5. doc: Describe calculation method of streaming start for pg_receivewal

  6. Add PostgresNode::command_fails_like()