From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Flush pgstats file during checkpoints |
Date: | 2024-07-12 12:10:26 |
Message-ID: | ZpEdMg1sm8hEVBx0@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-07-12 12:16:24 | Re: Amcheck verification of GiST and GIN |
Previous Message | Noah Misch | 2024-07-12 11:43:22 | Re: race condition when writing pg_control |