| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> | 
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> | 
| Cc: | Pandora <yeyukui(at)qq(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: fsync data directory after DB crash | 
| Date: | 2023-07-19 01:37:01 | 
| Message-ID: | CA+hUKGJVvehH9sFRUGA9cpvYtHFcKkpimm6e2CKH-cjq1CnygQ@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
On Wed, Jul 19, 2023 at 12:41 PM Michael Paquier <michael(at)paquier(dot)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:
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).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pandora | 2023-07-19 02:09:18 | 回复: fsync data directory after DB crash | 
| Previous Message | Michael Paquier | 2023-07-19 00:41:14 | Re: fsync data directory after DB crash |