Re: pg_dump, pg_dumpall and data durability - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: pg_dump, pg_dumpall and data durability
Date
Msg-id CAHGQGwFAr-dsf24+x-t6BxCA0C__KX6GS9zWuuan2WHance5kA@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump, pg_dumpall and data durability  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_dump, pg_dumpall and data durability  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Adding in docs the meaning of pg_stat_replication.sync_state
Next
From: Michael Paquier
Date:
Subject: Re: pg_dump, pg_dumpall and data durability