Re: pg_get_wal_replay_pause_state() should not return 'paused' while a promotion is ongoing.

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_get_wal_replay_pause_state() should not return 'paused' while a promotion is ongoing.
Date: 2021-05-18 08:52:42
Message-ID: CAFiTN-vRw0YJArBWAtdhr3NhvCvXbX6P-wf2FGPniZTLUcvxeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 18, 2021 at 1:43 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> > The fix looks fine but I think along with this we should also return
> > immediately from the pause loop if promotion is requested. Because if
> > we recheck the recovery pause then someone can pause again and we will
> > be in loop so better to exit as soon as promotion is requested, see
> > attached patch. Should be applied along with your patch.
>
> But this change can cause the recovery to continue with insufficient parameter
> settings if a promotion is requested while the server is in the paused state
> because of such invalid settings. This behavior seems not safe.
> If this my understanding is right, the recovery should abort immediately
> (i.e., FATAL error ""recovery aborted because of insufficient parameter settings"
> should be thrown) if a promotion is requested in that case, like when
> pg_wal_replay_resume() is executed in that case. Thought?

Yeah, you are right, I missed that.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-05-18 08:53:15 Re: [HACKERS] logical decoding of two-phase transactions
Previous Message Pavel Borisov 2021-05-18 08:18:15 Re: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump