Re: allow specifying action when standby encounters incompatible parameter settings

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: allow specifying action when standby encounters incompatible parameter settings
Дата
Msg-id CANbhV-F3HsTmgmApz-GTz6pfw-CPXy8FCrEXP8ruMSAu1kfjBA@mail.gmail.com
обсуждение исходный текст
Ответ на allow specifying action when standby encounters incompatible parameter settings  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: allow specifying action when standby encounters incompatible parameter settings  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Wed, 13 Apr 2022 at 22:35, Nathan Bossart <nathandbossart@gmail.com> wrote:

> As of 15251c0, when a standby encounters an incompatible parameter change,
> it pauses replay so that read traffic can continue while the administrator
> fixes the parameters.  Once the server is restarted, replay can continue.
> Before this change, such incompatible parameter changes caused the standby
> to immediately shut down.
>
> I noticed that there was some suggestion in the thread associated with
> 15251c0 [0] for making this behavior configurable, but there didn't seem to
> be much interest at the time.  I am interested in allowing administrators
> to specify the behavior before 15251c0 (i.e., immediately shut down the
> standby when an incompatible parameter change is detected).  The use-case I
> have in mind is when an administrator has automation in place for adjusting
> these parameters and would like to avoid stopping replay any longer than
> necessary.  FWIW this is what we do in RDS.

I don't understand why you need this patch at all.

Since you have automation, you can use that layer to automatically
restart all standbys at once, if you choose, without any help or
hindrance from PostgreSQL.

But I really don't want you to do that, since that results in loss of
availability of the service. I'd like you to try a little harder and
automate this in a way that allows the service to continue with some
standbys available while others restart.

All this feature does is allow you to implement things in a lazy way
that causes a loss of availability for users. I don't think that is of
benefit to PostgreSQL users, so -1 from me, on this patch (only),
sorry about that.

-- 
Simon Riggs                http://www.EnterpriseDB.com/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: some aspects of our qsort might not be ideal
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCH] Compression dictionaries for JSONB