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-03 11:20:19 |
Message-ID: | CAAJ_b96hYu-Hjd2P6fkVvfZZ=Kqj=bLGUx4sn9Ed0hzYPayD8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 3, 2021 at 12:08 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Tue, Mar 2, 2021 at 9:01 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> > >
> > > 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.
>
> I did not read the code for this, but let me ask something about this
> case. Why do we want checkpointer to convey the barrier to all the
> backend before completing the end of recovery checkpoint and other
> stuff? Is it because the system is still in WAL prohibited state?
Consider the previous case, where the user wants to change the system to
read-write. When a permitted user executes pg_prohibit_wal(false), the wal
prohibited state in shared memory updated to GOING_READ_WRITE
which is the transition state and then waits until the transition state
completes and the final state (i.e. READ_WRITE) gets updated
in shared memory. To set the final set is a job of the Checkpointer process.
We have integrated code into the Checkpointer process such that if it sees wal
prohibit transition state then it completes that as soon as possible by doing
necessary steps i.e. emitting super barriers, then update the final wal
prohibited state in shared memory and in control file.
> Is
> it possible that as soon as we get the pg_prohibit_wal(false) request
> the receiving backend start allowing the WAL writing for itself and
> finish the all post-recovery pending work and then inform the
> checkpointer to inform all other backends?
>
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.
Regards,
Amul
From | Date | Subject | |
---|---|---|---|
Next Message | Ajin Cherian | 2021-03-03 11:25:25 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | David Rowley | 2021-03-03 11:08:04 | Re: Why OR-clauses not getting copied into baserestrictinfo of another table whose columns are in the same EquivalenceClass? |