Re: [RFC] What should we do for reliable WAL archiving? - Mailing list pgsql-hackers

From MauMau
Subject Re: [RFC] What should we do for reliable WAL archiving?
Date
Msg-id 9C1EB95CA1F34DAB93DF549A51E3E874@maumau
Whole thread Raw
In response to Re: [RFC] What should we do for reliable WAL archiving?  (Mitsumasa KONDO <kondo.mitsumasa@gmail.com>)
Responses Re: [RFC] What should we do for reliable WAL archiving?
List pgsql-hackers
From: "Mitsumasa KONDO" <kondo.mitsumasa@gmail.com>
> 2014-03-17 21:12 GMT+09:00 Fujii Masao <masao.fujii@gmail.com>:
>
>> On Mon, Mar 17, 2014 at 10:20 AM, Robert Haas <robertmhaas@gmail.com>
>> wrote:
>> > On Sun, Mar 16, 2014 at 6:23 AM, MauMau <maumau307@gmail.com> wrote:
>> >> * Improve the example in the documentation.
>> >> But what command can we use to reliably sync just one file?
>> >>
>> >> * Provide some command, say pg_copy, which copies a file synchronously
>> by
>> >> using fsync(), and describes in the doc something like "for simple use
>> >> cases, you can use pg_copy as the standard reliable copy command."
>> >
>> > +1.  This won't obviate the need for tools to manage replication, but
>> > it would make it possible to get the simplest case right without
>> > guessing.
>>
>> +1, too.
>>
>> And, what about making pg_copy call posix_fadvise(DONT_NEED) against the
>> archived file after the copy? Also It might be good idea to support the
>> direct
>> copy of the file to avoid wasting the file cache.
>
> Use direct_cp.
> http://directcp.sourceforge.net/direct_cp.html

Thank you all for giving favorable responses and interesting ideas.
Then, I think I'll do:

* Create pg_copy in C so that it can be used on Windows as well as on 
UNIX/Linux.  It just copies one file.  Its source code is located in 
src/bin/pg_copy/.  Please recommend a better name if you have one in mind.

* Add a reference page for pg_copy in the chapter "Server applications". 
Modify the section for continuous archiving to recommend pg_copy for simple 
use cases as the standard command.

* pg_copy calls posix_fadvise(DONT_NEED) on the destination file.

* pg_copy passes O_DIRECT flag when opening the destination file 
when --directio or -d option is specified.  O_DIRECT is not used by default 
because it may not be available on some file systems, as well as it might 
cause trouble on older platforms such as RHEL4/5.  pg_copy does not use 
O_DIRECT for the source file so that it can copy the data from the 
filesystem cache, which is just written by postgres.

Could you give me your opinions before starting the work, including the 
following?

* Should I refactor the functions (copy_file, copydir, etc.) in 
src/backend/storage/file/copydir.c so that they can also be used for 
frontends?  If so, which of src/port or src/common/ is the right place to 
put copydir.c in?

* Should I complete the work before 9.4 beta so that it will be available 
starting with 9.4?  I think so because it is a basic capability to archive 
transaction logs safely (although the time may not allow me to do this).

Regards
MauMau




pgsql-hackers by date:

Previous
From: Rajeev rastogi
Date:
Subject: Re: Standby server won't start
Next
From: "MauMau"
Date:
Subject: Re: Standby server won't start