Re: [Patch] ALTER SYSTEM READ ONLY

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Amul Sul <sulamul(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Patch] ALTER SYSTEM READ ONLY
Date: 2021-03-02 15:31:41
Message-ID: CAFiTN-twgtETJc0VeKE0K_gFiQFiidYiuMfnd4tidLXrVTCuug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 2, 2021 at 7:54 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> XLogAcceptWrites() tried to club all the WAL write operations that happen at the
> end of StartupXLOG(). The only exception is that promotion checkpoint.

Okay, I was expecting that XLogAcceptWrites should have all the WAL
write-related operations which should either executed at the end of
StartupXLOG() if the system is not read-only or after the system is
set back to read-write. But promotion-related code is completely
irrelevant when it is executed from PerformPendingStartupOperations.
So I am not entirely sure that whether we want to keep those stuff in
XLogAcceptWrites.

> > That will look cleaner.
>
> I think it would be better to move the promotion checkpoint call inside
> XLogAcceptWrites() as well. So that we can say XLogAcceptWrites() is a part of
> StartupXLOG() does the required WAL writes. Thoughts?

Okay so if we want to keep all the WAL write inside XLogAcceptWrites
including promotion-related stuff then +1 for moving this also inside
XLogAcceptWrites.

> > >
> > > 1] http://postgr.es/m/CA+TgmoZ=CCTbAXxMTYZoGXEgqzOz9smkBWrDpsacpjvFcGCuaw@mail.gmail.com
> > > 2] http://postgr.es/m/CAAJ_b97xX-nqRyM_uXzecpH9aSgoMROrDNhrg1N51fDCDwoy2g@mail.gmail.com
> >
> > 2.
> > I did not clearly understand your concern in point [2], because of
> > which you have to postpone RECOVERY_STATE_DONE untill system is set
> > back to read-write. Can you explain this?
> >
>
> Sure, for that let me explain how this transition to read-write occurs. When a
> backend executes a function (ie. pg_prohibit_wal(false)) to make the system
> read-write then that system state changes will be conveyed by the Checkpointer
> process to all existing backends using global barrier and while Checkpointer in
> the progress of conveying this barrier, any existing backends who might have
> absorbed barriers can write new records.
>
> We don't want that to happen in cases where previous recovery-end-checkpoint is
> skipped in startup. We want Checkpointer first to convey the barrier to all
> backends but, the backend shouldn't write wal until the Checkpointer writes
> recovery-end-checkpoint record.
>
> To refrain these backends from writing WAL I think we should keep the server in
> crash recovery mode until UpdateFullPageWrites(),
> end-of-recovery-checkpoint, and XLogReportParameters() are performed.

Thanks for the explanation. Now, I understand the problem, however, I
am not sure that whether keeping the system in recovery is the best
way to solve this but as of now I don't have anything better to
suggest, and immediately I couldn’t think of any problem with this
solution. But I will think about this again.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-03-02 16:40:21 GiST comment improvement
Previous Message Mark Dilger 2021-03-02 15:28:05 Re: [PATCH] Support empty ranges with bounds information