Re: Slightly improve initdb --sync-only option's help message
От | Bossart, Nathan |
---|---|
Тема | Re: Slightly improve initdb --sync-only option's help message |
Дата | |
Msg-id | 8A92C19F-6EF2-452F-A8CB-C714DC981AC6@amazon.com обсуждение исходный текст |
Ответ на | Re: Slightly improve initdb --sync-only option's help message (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: Slightly improve initdb --sync-only option's help message
Re: Slightly improve initdb --sync-only option's help message |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: