On Wed, Feb 12, 2020 at 06:11:06PM +0900, Fujii Masao wrote:
> On 2020/02/12 7:53, Jehan-Guillaume de Rorthais wrote:
>> In my humble opinion, I prefer the previous behavior, streaming without
>> temporary slot, for one reason: primary availability.
>
> +1
>
>> 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.
Even with that, are we sure this extra feature would be a reason
sufficient to change the default value of this option to be enabled?
I am not sure about that either. My opinion is that this option is
useful to have and that it is not really a problem if you have slot
monitoring on the primary (or a standby for cascading). And I'd like
to believe that it is a common practice lately for base backups,
archivers based on pg_receivewal or even logical decoding, but it
could be surprising for some users who do not do that yet. So
Jehan-Guillaume's arguments sound also sensible to me (he also
maintains an automatic failover solution called PAF).
From what I can see nobody really likes the current state of things
for this option, and that does not come down only to its default
value. The default GUC value and the way the parameter is loaded by
the WAL sender are problematic, still easy enough to fix. How do we
move on from here? I could post a patch based on what Sergei Kornilov
has sent around [1], but that's Peter's feature. Any opinions?
[1]: https://www.postgresql.org/message-id/20200122055510.GH174860@paquier.xyz
--
Michael
