On 2020-01-23 21:49, Robert Haas wrote:
> On Tue, Jan 14, 2020 at 8:57 AM Peter Eisentraut <peter@eisentraut.org> wrote:
>> walreceiver uses a temporary replication slot by default
>>
>> If no permanent replication slot is configured using
>> primary_slot_name, the walreceiver now creates and uses a temporary
>> replication slot. A new setting wal_receiver_create_temp_slot can be
>> used to disable this behavior, for example, if the remote instance is
>> out of replication slots.
>>
>> Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
>> Discussion:
https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com
>
> Neither the commit message for this patch nor any of the comments in
> the patch seem to explain why this is a desirable change.
>
> I assume that's probably discussed on the thread that is linked here,
> but you shouldn't have to dig through the discussion thread to figure
> out what the benefits of a change like this are.
You are right, this has gotten a bit lost in the big thread.
The rationale is basically the same as why client-side tools like
pg_basebackup use a temporary slot: So that the WAL data that they are
interested in doesn't disappear while they are connected.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
