Re: replay pause vs. standby promotion

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: replay pause vs. standby promotion
Date: 2020-03-06 13:18:26
Message-ID: 9e12f72c-655d-9022-65dd-5441c768aec2@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/03/04 23:40, Jehan-Guillaume de Rorthais wrote:
> On Wed, 04 Mar 2020 15:00:54 +0300
> Sergei Kornilov <sk(at)zsrv(dot)org> wrote:
>
>> Hello
>>
>>> I want to start this discussion because this is related to the patch
>>> (propoesd at the thread [1]) that I'm reviewing. It does that partially,
>>> i.e., prefers the promotion only when the pause is requested by
>>> recovery_target_action=pause. But I think that it's reasonable and
>>> more consistent to do that whether whichever the pause is requested
>>> by pg_wal_replay_pause() or recovery_target_action.
>>
>> +1.
>
> +1
>
> And pg_wal_replay_pause () should probably raise an error explaining the
> standby ignores the pause because of ongoing promotion.

OK, so patch attached.

This patch causes, if a promotion is triggered while recovery is paused,
the paused state to end and a promotion to continue. OTOH, this patch
makes pg_wal_replay_pause() and _resume() throw an error if it's executed
while a promotion is ongoing.

Regarding recovery_target_action, if the recovery target is reached
while a promotion is ongoing, "pause" setting will act the same as "promote",
i.e., recovery will finish and the server will start to accept connections.

To implement the above, I added new shared varible indicating whether
a promotion is triggered or not. Only startup process can update this shared
variable. Other processes like read-only backends can check whether
promotion is ongoing, via this variable.

I added new function PromoteIsTriggered() that returns true if a promotion
is triggered. Since the name of this function and the existing function
IsPromoteTriggered() are confusingly similar, I changed the name of
IsPromoteTriggered() to IsPromoteSignaled, as more appropriate name.

I'd like to apply the change of log message that Sergei proposed at [1]
after commiting this patch if it's ok.

[1]
https://www.postgresql.org/message-id/flat/19168211580382043(at)myt5-b646bde4b8f3(dot)qloud-c(dot)yandex(dot)net

Regards,

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

Attachment Content-Type Size
prefer_promote_than_pause_v1.patch text/plain 8.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-03-06 13:22:20 Re: Should we remove a fallback promotion? take 2
Previous Message Julien Rouhaud 2020-03-06 13:15:47 Add an optional timeout clause to isolationtester step.