Re: Slightly improve initdb --sync-only option's help message - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Slightly improve initdb --sync-only option's help message
Date
Msg-id 093F6983-BC0E-4839-8079-95ABC3FD8873@amazon.com
Whole thread Raw
In response to Re: Slightly improve initdb --sync-only option's help message  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On 7/22/21, 6:31 PM, "Justin Pryzby" <pryzby@telsasoft.com> wrote:
> On Thu, Jul 22, 2021 at 10:32:18PM +0000, Bossart, Nathan wrote:
>> IMO the note about the option being helpful after using the --no-sync
>> option would fit better in the docs, but I'm struggling to think of a
>> use case for using --no-sync and then calling initdb again with
>> --sync-only.  Why wouldn't you just leave out --no-sync the first
>> time?
>
> It's to allow safely running bulk loading with fsync=off - if the bulk load
> fails, you can wipe out the partially-loaded cluster and start over.
> But then transitioning to a durable state requires not just setting fsync=on,
> which enables future fsync calls.  It also requires syncing all dirty buffers.

Right.  Perhaps the documentation for --sync-only could mention this
use-case instead.

        Safely write all database files to disk and exit. This does
        not perform any of the normal initdb operations.  Generally,
        this option is useful for ensuring reliable recovery after
        changing fsync from off to on.

Nathan


pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Corrected documentation of data type for the logical replication message formats.
Next
From: Mark Dilger
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)