Re: [Patch] ALTER SYSTEM READ ONLY

From: Amul Sul <sulamul(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(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-04 17:51:32
Message-ID: CAAJ_b946222LZ9XyHh4yMJv2N7aT1VObcgtRZC-fhXHkVpAqsQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 3, 2021 at 7:56 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Wed, Mar 3, 2021 at 4:50 PM Amul Sul <sulamul(at)gmail(dot)com> wrote:
> >
> > On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > Yes, it is possible to allow wal temporarily for itself by setting
> > LocalXLogInsertAllowed, but when we request Checkpointer for the end-of-recovery
> > checkpoint, the first thing it will do is that wal prohibit state transition
> > then recovery-end-checkpoint.
> >
> > Also, allowing WAL write in read-only (WAL prohibited state) mode is against
> > this feature principle.
>
> So IIUC before the checkpoint change the state in the control file we
> anyway inform other backend and then they are allowed to write the WAL
> is the right? If that is true then what is the problem in first doing
> the pending post-recovery process and then informing the backend about
> the state change. I mean we are in a process of changing the state to
> read-write so why it is necessary to inform all the backend before we
> can write WAL? Are we afraid that after we write the WAL and if there
> is some failure before we make the system read-write then it will
> break the principle of the feature, I mean eventually system will stay
> read-only but we wrote the WAL? If so then currently, are we assuring
> that once we inform the backend and backend are allowed to write the
> WAL there are no chances of failure and the system state is guaranteed
> to be changed. If all that is true then I will take my point back.
>

The wal prohibit state transition handling code is integrated into various
places of the checkpointer process so that it can pick state changes as soon as
possible. Before informing other backends we can do UpdateFullPageWrites() but
when we try to next the end-of-recovery checkpoint write operation, the
Checkpointer will hit ProcessWALProhibitStateChangeRequest() first which will
try for the wal prohibit transition state completion and then write
the checkpoint
record.

Regards,
Amul

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-03-04 17:52:28 Re: Shared memory size computation oversight?
Previous Message Juan José Santamaría Flecha 2021-03-04 17:37:56 Re: Add support for PROVE_FLAGS and PROVE_TESTS in MSVC scripts