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-03 06:37:53 |
Message-ID: | CAFiTN-tu5nUK1SH8i1SKMggadekxnmWHzP_HBOKW2_F1gtqJkQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? 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?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2021-03-03 06:47:42 | Re: PITR promote bug: Checkpointer writes to older timeline |
Previous Message | Michael Paquier | 2021-03-03 06:30:17 | Re: cryptohash: missing locking functions for OpenSSL <= 1.0.2? |