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
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. |