Re: Flush pgstats file during checkpoints - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Flush pgstats file during checkpoints
Date
Msg-id ZpEdMg1sm8hEVBx0@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Flush pgstats file during checkpoints  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Flush pgstats file during checkpoints
Re: Flush pgstats file during checkpoints
List pgsql-hackers
Hi,

On Fri, Jul 12, 2024 at 03:42:21PM +0900, Michael Paquier wrote:
> On Fri, Jul 05, 2024 at 01:52:31PM +0900, Michael Paquier wrote:
> > On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote:
> >> I think those are two independent issues - knowing that the snapshot is
> >> from the last checkpoint, and knowing that it's correct (not corrupted).
> >> And yeah, we should be careful about fsync/durable_rename.
> > 
> > Yeah, that's bugging me as well.  I don't really get why we would not
> > want durability at shutdown for this data.  So how about switching the
> > end of pgstat_write_statsfile() to use durable_rename()?  Sounds like
> > an independent change, worth on its own.
> 
> Please find attached a rebased patch set with the durability point
> addressed in 0001.  There were also some conflicts.

Thanks!

Looking at 0001:

+               /* error logged already */

Maybe mention it's already logged by durable_rename() (like it's done in
InstallXLogFileSegment(), BaseBackup() for example).

Except this nit, 0001 LGTM.

Need to spend more time and thoughts on 0002+.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: race condition when writing pg_control
Next
From: Tomas Vondra
Date:
Subject: Re: Amcheck verification of GiST and GIN