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
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 |