Re: Is it correct to update db state in control file as "shutting down" during end-of-recovery checkpoint?

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, PostgreSQL Hackers <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: 2021-12-08 11:27:55
Message-ID: CALj2ACXW-qC+gUFo4WUi2fkHn+MB0gK3EH7r=gU1jTtjkSbGmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 8, 2021 at 1:05 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Wed, 8 Dec 2021 11:47:30 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > On Wed, Dec 8, 2021 at 10:59 AM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> > > >> Another option we might want to consider is to just skip updating the
> > > >> state entirely for end-of-recovery checkpoints. The state would
> > > >> instead go straight from DB_IN_CRASH_RECOVERY to DB_IN_PRODUCTION. I
> > > >> don't know if it's crucial to have a dedicated control file state for
> > > >> end-of-recovery checkpoints.
>
> FWIW I find it simple but sufficient since I regarded the
> end-of-recovery checkpoint as a part of recovery. In that case what
> is strange here is only that the state transition passes the
> DB_SHUTDOWN(ING/ED) states.
>
> On the other hand, when a server is going to shutdown, the state stays
> at DB_IN_PRODUCTION if there are clinging clients even if the shutdown
> procedure has been already started and no new clients can connect to
> the server. There's no reason we need to be so particular about states
> for recovery-end.
>
> I see it a bit too complex for the advantage. When end-of-recovery
> checkpoint takes so long, that state is shown in server log, which
> operators would look into before the control file.

Thanks for your thoughts. I'm fine either way, hence attaching two
patches here with and I will leave it for the committer 's choice.
1) v1-0001-Add-DB_IN_END_OF_RECOVERY_CHECKPOINT-state-for-co.patch --
adds new db state DB_IN_END_OF_RECOVERY_CHECKPOINT for control file.
2) v1-0001-Skip-control-file-db-state-updation-during-end-of.patch --
just skips setting db state to DB_SHUTDOWNING and DB_SHUTDOWNED in
case of end-of-recovery checkpoint so that the state will be
DB_IN_CRASH_RECOVERY which then changes to DB_IN_PRODUCTION.

Regards,
Bharath Rupireddy.

Attachment Content-Type Size
v1-0001-Add-DB_IN_END_OF_RECOVERY_CHECKPOINT-state-for-co.patch application/x-patch 3.4 KB
v1-0001-Skip-control-file-db-state-updation-during-end-of.patch application/x-patch 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2021-12-08 11:52:28 Re: row filtering for logical replication
Previous Message Bharath Rupireddy 2021-12-08 11:27:49 Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display