Horton

Re: pg_receivewal starting position

Ronan Dunklau <ronan.dunklau@aiven.io>

View thread View on postgr.es
From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2021-10-26T09:01:46Z
Lists: pgsql-hackers

Attachments

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.

-- 
Ronan Dunklau

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()