Peter Eisentraut <peter_e@gmx.net> wrote:
> On 8/11/14 6:23 PM, MauMau wrote:
>
>> I submitted a patch a patch for this a few months ago, which is pg_copy
>> listed in the current CF. The patch also addresses the problem that the
>> archived file can get lost after power failure because it is not flushed
>> to disk. The patch consists of a program called pg_copy which can be
>> used instead of cp/copy, and a doc fix to suggest using mv. I made it
>> following the favorable suggestions from people.
>
> I realize that there are about 128 different ways people set this up
> (which is itself a problem), but it appears to me that a solution like
> pg_copy only provides local copying, which implies the use of something
> like NFS.
Not necessarily. What I have done is to use the cp/mv technique on
the database server and then rsync (through ssh) from each place
that needs it. That seems to me much less fragile than copying to
an NFS mount point.
> Also, I think you can get local copy+fsync with dd.
Does the directory entry only become visible to other processes
once the file is complete when you use dd?
> The alternatives of doing remote copying inside archive_command are also
> questionable if you have multiple standbys.
Right. It's a nightmare to try to design anything to serve
multiple standbys without having the initial archive be local and
copying from that archive to the others. At least, if there is
some other good solution, I have yet to see it.
The above is regarding WAL file archiving -- I'm not putting down
streaming replication. Of course, what I would have *really* liked
is a WAL receiver that could write out normal-looking WAL files for
archiving purposes and pass through the WAL stream to a hot
standby. Last I checked (which was admittedly at least a couple
years back) there was no such utility, although I seem to remember
that Magnus had done some work that looked like it could be bent to
that end.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company