Re: pgsql: walreceiver uses a temporary replication slot by default

On 2020/02/12 7:53, Jehan-Guillaume de Rorthais wrote:
> Hello,
>
> On Mon, 10 Feb 2020 16:37:53 +0100
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
>> On 2020-01-23 21:49, Robert Haas wrote:
>>> On Tue, Jan 14, 2020 at 8:57 AM Peter Eisentraut <peter(at)eisentraut(dot)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(dot)sawada(at)2ndquadrant(dot)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.
>
> In my humble opinion, I prefer the previous behavior, streaming without
> temporary slot, for one reason: primary availability.

+1

> Should the standby lag far behind the primary (no matter the root cause),
> the standby was disconnected because of missing WAL. Worst case scenario, we
> must rebuild it, hopefully from backups. Best case scenario, it fetches WALs
> from PITR backup. As soon as the later is possible in the stack, I consider slot
> like a burden from the operability point of view. If standbys can not fetch
> archived WAL from PITR, then we can consider slots.
>
> With temp slot created by default, if one standby lag far behind, it can make
> the primary unavailable. We have nothing yet to forbid a slot to fill the
> pg_wal partition. How new users creating their first cluster would react in such
> situation? I suppose the original discussion was mostly targeting them?
> Recovering from this is way more scary than building a standby.
>
> So the default behavior might not be desirable and maybe
> wal_receiver_create_temp_slot might be off by default?
>
> Note that Kyotaro HORIGUCHI is working on a patch to restricting maximum keep
> segments by repslots:
>
> https://www.postgresql.org/message-id/flat/20190627162256.4f4872b8%40firost#6cba1177f766e7ffa5237789e748da38

Yeah, I think it's better to disable this option until something like
Horiguchi-san's proposal will have been committed, i.e., until
the upper limit on the number (or size) of WAL files that remain
for slots become configurable.

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters