Re: fsync data directory after DB crash - Mailing list pgsql-general

From Thomas Munro
Subject Re: fsync data directory after DB crash
Date
Msg-id CA+hUKGJVvehH9sFRUGA9cpvYtHFcKkpimm6e2CKH-cjq1CnygQ@mail.gmail.com
Whole thread Raw
In response to Re: fsync data directory after DB crash  (Michael Paquier <michael@paquier.xyz>)
Responses 回复: fsync data directory after DB crash
List pgsql-general
On Wed, Jul 19, 2023 at 12:41 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Jul 18, 2023 at 04:50:25PM +0800, Pandora wrote:
> > I found that starting from version 9.5, PostgreSQL will do fsync on
> > the entire data directory after DB crash. Here's a question: if I
> > have FPW = on, why is this step still necessary?
>
> Yes, see around the call of SyncDataDirectory() in xlog.c:
>  * - There might be data which we had written, intending to fsync it, but
>  *   which we had not actually fsync'd yet.  Therefore, a power failure in
>  *   the near future might cause earlier unflushed writes to be lost, even
>  *   though more recent data written to disk from here on would be
>  *   persisted.  To avoid that, fsync the entire data directory.

FTR there was some discussion and experimental patches that would add
recovery_init_sync_method=none and recovery_init_sync_method=wal,
which are based on the OP's observation + an idea for how to make it
work even without FPWs enabled:


https://www.postgresql.org/message-id/flat/CA%2BhUKGKgj%2BSN6z91nVmOmTv2KYrG7VnAGdTkWdSjbOPghdtooQ%40mail.gmail.com#576caccf21cb6c3e883601fceb28d36b

Only recovery_init_sync_method=syncfs actually went in from that
thread.  It works better for some setups (systems where opening
squillions of files just do perform a no-op fsync() is painfully
expensive).



pgsql-general by date:

Previous
From: Michael Paquier
Date:
Subject: Re: fsync data directory after DB crash
Next
From: "Pandora"
Date:
Subject: 回复: fsync data directory after DB crash