From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | 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 05:29:28 |
Message-ID: | 95A20A82-6B3D-4529-A288-B352CEFAB417@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/7/21, 8:42 PM, "Bharath Rupireddy" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> On Wed, Dec 8, 2021 at 9:49 AM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>> I think that's alright. The only other small suggestion I have would
>> be to say "during end-of-recovery checkpoint" instead of "while in
>> end-of-recovery checkpoint."
>
> "while in" is being used by DB_IN_CRASH_RECOVERY and
> DB_IN_ARCHIVE_RECOVERY messages. I don't think it's a good idea to
> deviate from that and use "during".
Fair enough. I don't have a strong opinion about this.
>> 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.
>
> Please note that end-of-recovery can take a while in production
> systems (we have observed such things working with our customers) and
> anything can happen during that period of time. The end-of-recovery
> checkpoint is not something that gets finished momentarily. Therefore,
> having a separate db state in the control file is useful.
Is there some useful distinction between the states for users? ISTM
that users will be waiting either way, and I don't know that an extra
control file state will help all that much. The main reason I bring
up this option is that the list of states is pretty short and appears
to be intended to indicate the high-level status of the server. Most
of the states are over 20 years old, and the newest one is over 10
years old, so I don't think new states can be added willy-nilly.
Of course, I could be off-base and others might agree that this new
state would be nice to have.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | tanghy.fnst@fujitsu.com | 2021-12-08 05:37:28 | RE: [PATCH]Comment improvement in publication.sql |
Previous Message | Amit Kapila | 2021-12-08 05:24:47 | Re: row filtering for logical replication |