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
signature.asc
Description: PGP signature