Horton

Re: pg_receivewal starting position

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Ronan Dunklau <ronan.dunklau@aiven.io>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, bharath.rupireddyforpostgres@gmail.com, pgsql-hackers@lists.postgresql.org, sawada.mshk@gmail.com
Date: 2021-09-02T08:37:20Z
Lists: pgsql-hackers 
On Thu, Sep 02, 2021 at 10:08:26AM +0200, Ronan Dunklau wrote:
> I could see the use for sending active_pid for use within pg_basebackup: at 
> least we could fail early if the slot is already in use. But at the same time, 
> maybe it won't be in use anymore once we need it.

There is no real concurrent protection with this design.  You could
read that the slot is not active during READ_REPLICATION_SLOT just to
find out after in the process of pg_basebackup streaming WAL that it
became in use in-between.  And the backend-side protections would kick
in at this stage.

Hmm.  The logic doing the decision-making with pg_receivewal may
become more tricky when it comes to pg_replication_slots.wal_status,
max_slot_wal_keep_size and pg_replication_slots.safe_wal_size.  The
number of cases we'd like to consider impacts directly the amount of
data send through READ_REPLICATION_SLOT.  That's not really different
than deciding of a failure, a success or a retry with active_pid at an
earlier or a later stage of a base backup.  pg_receivewal, on the
contrary, can just rely on what the backend tells when it begins
streaming.  So I'd prefer keeping things simple and limit the number
of fields a minimum for this command.
--
Michael

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