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 8A92C19F-6EF2-452F-A8CB-C714DC981AC6@amazon.com
Whole thread Raw
In response to Re: Slightly improve initdb --sync-only option's help message  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Slightly improve initdb --sync-only option's help message  (Gurjeet Singh <gurjeet@singh.im>)
Re: Slightly improve initdb --sync-only option's help message  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On 7/23/21, 9:09 AM, "Bossart, Nathan" <bossartn@amazon.com> wrote:
> 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.

Here are my suggestions in patch form.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Fix around conn_duration in pgbench
Next
From: Arne Roland
Date:
Subject: Re: Rename of triggers for partitioned tables