From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | nathandbossart(at)gmail(dot)com, bossartn(at)amazon(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, jcasanov(at)systemguards(dot)com(dot)ec, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint? |
Date: | 2022-01-29 02:12:50 |
Message-ID: | YfSiolXYhaI8E5wc@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 28, 2022 at 06:32:27PM +0900, Kyotaro Horiguchi wrote:
> End-of-recovery checkpoint is requested as CHECKPOINT_WAIT, which
> seems to me to mean the state is always DB_IN_ARCHIVE_RECOVERY while
> the checkpoint is running?
With the patch, yes, we would keep the control file under
DB_IN_{ARCHIVE,CRASH}_RECOVERY during the whole period of the
end-of-recovery checkpoint. On HEAD, we would have DB_SHUTDOWNING
until the end-of-recovery checkpoint completes, after which we switch
to DB_SHUTDOWNED for a short time before DB_IN_PRODUCTION.
> If correct, if server is killed druing the
> end-of-recovery checkpoint, the state stays DB_IN_ARCHIVE_RECOVERY
> instead of DB_SHUTDOWNING or DB_SHUTDOWNED. AFAICS there's no
> differece between the first two at next startup.
One difference is the hint given to the user at the follow-up startup.
Crash and archive recovery states can freak people easily as they
mention the risk of corruption. Using DB_SHUTDOWNING reduces this
window.
> I dont' think DB_SHUTDOWNED case is not worth considering here.
Well, this patch also means there is a small window where we have
DB_IN_ARCHIVE_RECOVERY in the control file with the new timeline and
minRecoveryPoint not set, rather than DB_SHUTDOWNED.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-01-29 02:19:12 | Re: make MaxBackends available in _PG_init |
Previous Message | Michael Paquier | 2022-01-29 00:53:25 | Re: pg_upgrade should truncate/remove its logs before running |