Re: pg_dump, pg_dumpall and data durability

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: pg_dump, pg_dumpall and data durability
Дата
Msg-id CAHGQGwFAr-dsf24+x-t6BxCA0C__KX6GS9zWuuan2WHance5kA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump, pg_dumpall and data durability  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_dump, pg_dumpall and data durability  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Nov 16, 2016 at 1:27 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sun, Nov 13, 2016 at 4:18 AM, Andres Freund <andres@anarazel.de> wrote:
>> On 2016-11-08 18:18:01 -0500, Tom Lane wrote:
>>> I think this might be better addressed by adding something to backup.sgml
>>> pointing out that you'd better fsync or sync your backups before assuming
>>> that they can't be lost.
>>
>> How does a normal user do that? I don't think there's a cross-platform
>> advice we can give, and even on *nix the answer basically is 'sync;
>> sync;' which is a pretty big hammer, and might be completely
>> unacceptable on a busy server.
>
> Yeah, that's a pretty fair point.  I see the point of this patch
> pretty clearly but somehow it makes me nervous anyway.  I'm not sure
> there's any better alternative to what's being proposed, though.

One idea is to provide the utility or extension which fsync's the specified
files and directories (including all the files under them). It may be overkill,
though. But it would be useful for other purposes, for example, we can
improve the durability of archived WAL files by setting this utility in
archive_command, and we can flush any output files generated by psql
by using it.

Regards,

-- 
Fujii Masao



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Adding in docs the meaning of pg_stat_replication.sync_state
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_dump, pg_dumpall and data durability