Re: Slightly improve initdb --sync-only option's help message

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Gurjeet Singh <gurjeet(at)singh(dot)im>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Slightly improve initdb --sync-only option's help message
Date: 2021-07-23 16:08:51
Message-ID: 093F6983-BC0E-4839-8079-95ABC3FD8873@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/22/21, 6:31 PM, "Justin Pryzby" <pryzby(at)telsasoft(dot)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

In response to

Browse pgsql-hackers by date

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