Re: pg_dump, pg_dumpall and data durability

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: pg_dump, pg_dumpall and data durability
Дата
Msg-id A737B7A37273E048B164557ADEF4A58B5397BFFF@ntex2010i.host.magwien.gv.at
обсуждение исходный текст
Ответ на Re: pg_dump, pg_dumpall and data durability  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: pg_dump, pg_dumpall and data durability
Список pgsql-hackers
Michael Paquier wrote:
> A typo s/pre_fsync_fname/pre_sync_fname, and a mistake from me because
> I did not compile with -DPG_FLUSH_DATA_WORKS to check this code.
> 
> v2 is attached, fixing those issues.

The patch applies and compiles fine.

I have tested it on Linux and MinGW and could see the fsync(2) and
FlushFileBuffers calls I expected.
This adds crash safety for a reasonable price, and I think we should have that.

The documentation additions are sufficient.

Looking through the patch, I had two questions that are more about
style and consistency than anything else:

- In pg_dumpall.c, the result of fsync_fname() is cast to "void" to show that the return code is ignored, but not
anywhereelse.  Is that by design?
 

- For pg_dumpall, a short option "-N" is added for "--no-sync", but not for pg_dump (because -N is already taken
there).I'd opt for either using the same short option for both or (IMO better) only offering a long option for both.
Thiswould avoid confusion, and we expect that few people will want to use this option anyway, right?
 

Yours,
Laurenz Albe

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Improving RLS planning