From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Patch] ALTER SYSTEM READ ONLY |
Date: | 2021-02-19 12:13:08 |
Message-ID: | CAAJ_b96Yb4jaW6oU1bVYEBaf=TQ-QL+mMT1ExfwvNZEr7XRyoQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 17, 2021 at 7:50 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2021-02-16 17:11:06 -0500, Robert Haas wrote:
Thank you very much to both of you !
> > I can't promise that what I'm about to write is an entirely faithful
> > representation of what he said, but hopefully it's not so far off that
> > he gets mad at me or something.
>
> Seems accurate - and also I'm way too tired that I'd be mad ;)
>
>
> > 1. If the server starts up and is read-only and
> > ArchiveRecoveryRequested, clear the read-only state in memory and also
> > in the control file, log a message saying that this has been done, and
> > proceed. This makes some other cases simpler to deal with.
>
> It seems also to make sense from a behaviour POV to me: Imagine a
> "smooth" planned failover with ASRO:
> 1) ASRO on primary
> 2) promote standby
> 3) edit primary config to include primary_conninfo, add standby.signal
> 4) restart "read only primary"
>
> There's not really any spot in which it'd be useful to do disable ASRO,
> right? But 4) should make the node a normal standby.
>
Understood.
In the attached version I have made the changes accordingly what Robert has
summarised in his previous mail[1].
In addition to that, I also move the code that updates the control file to
XLogAcceptWrites() which will also get skipped when the system is read-only (wal
prohibited). The system will be in the crash recovery, and that will
change once we do the end-of-recovery checkpoint and the WAL writes operation
which we were skipping from startup. The benefit of keeping the system in
recovery mode is that it fixes my concern[2] where other backends could connect
and write wal records while we were changing the system to read-write. Now, no
other backends allow a wal write; UpdateFullPageWrites(), end-of-recovery
checkpoint, and XLogReportParameters() operations will be performed in the same
sequence as it is in the startup while changing the system to read-write.
Regards,
Amul
1] http://postgr.es/m/CA+TgmoZ=CCTbAXxMTYZoGXEgqzOz9smkBWrDpsacpjvFcGCuaw@mail.gmail.com
2] http://postgr.es/m/CAAJ_b97xX-nqRyM_uXzecpH9aSgoMROrDNhrg1N51fDCDwoy2g@mail.gmail.com
Attachment | Content-Type | Size |
---|---|---|
v15-0001-Implement-wal-prohibit-state-using-global-barrie.patch | application/x-patch | 53.6 KB |
v15-0003-WIP-Documentation.patch | application/x-patch | 6.5 KB |
v15-0002-Error-or-Assert-before-START_CRIT_SECTION-for-WA.patch | application/x-patch | 69.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Damir Simunic | 2021-02-19 12:29:57 | Re: Extensibility of the PostgreSQL wire protocol |
Previous Message | iwata.aya@fujitsu.com | 2021-02-19 11:23:33 | RE: libpq debug log |