Re: Deduplicate code updating ControleFile's DBState.

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Amul Sul <sulamul(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Deduplicate code updating ControleFile's DBState.
Date: 2021-11-10 20:00:02
Message-ID: 9928EE76-62C3-402A-9CF4-344DDC79A5B1@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/1/21, 10:40 PM, "Michael Paquier" <michael(at)paquier(dot)xyz> wrote:
> On Fri, Oct 01, 2021 at 05:47:45PM +0000, Bossart, Nathan wrote:
>> I'm inclined to agree that anything that calls update_controlfile()
>> should update the timestamp.
>
> pg_control.h tells that:
> pg_time_t time; /* time stamp of last pg_control update */
> So, yes, that would be more consistent.
>
>> However, I wonder if the additional
>> calls to time() would have a noticeable impact.
>
> I would not take that lightly either. Now, I don't think that any of
> the code paths where UpdateControlFile() or update_controlfile() is
> called are hot enough to worry about that.
>
> UpdateControlFile(void)
> {
> + ControlFile->time = (pg_time_t) time(NULL);
> update_controlfile(DataDir, ControlFile, true);
> }
> I have to admit that it is a bit strange to do that in the backend but
> not the frontend, so there is a good argument for doing that directly
> in update_controlfile(). pg_resetwal does an update of the time, but
> pg_rewind does not.

I don't see any recent updates to this thread from Amul, so I'm
marking this one as waiting-for-author.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-11-10 20:06:12 SIGABRT causes messages at LOG but not PANIC
Previous Message Bossart, Nathan 2021-11-10 19:45:23 Re: Isn't it better with "autovacuum worker...." instead of "worker took too long to start; canceled" specific to "auto