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-26 18:05:50 |
Message-ID: | 8A92C19F-6EF2-452F-A8CB-C714DC981AC6@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/23/21, 9:09 AM, "Bossart, Nathan" <bossartn(at)amazon(dot)com> wrote:
> 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.
Here are my suggestions in patch form.
Nathan
Attachment | Content-Type | Size |
---|---|---|
v2-0001-improve-initdb-sync-only-help-message-and-docs.patch | application/octet-stream | 1.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Arne Roland | 2021-07-26 18:11:28 | Re: Rename of triggers for partitioned tables |
Previous Message | Fujii Masao | 2021-07-26 18:04:35 | Re: Fix around conn_duration in pgbench |