References: <53E5603B.5040102@agliodbs.com>
 <1407777686.41146.YahooMailNeo@web122306.mail.ne1.yahoo.com>
 <0F73426A2EA544878BCAC33BB989D671@maumau> <53EBCCEA.3090604@gmx.net>
Message-ID: <1407965034.12878.YahooMailNeo@web122304.mail.ne1.yahoo.com>
Date: Wed, 13 Aug 2014 14:23:54 -0700
From: Kevin Grittner <kgrittn@ymail.com>
Reply-To: Kevin Grittner <kgrittn@ymail.com>
Subject: Re: Sample archive_command is still problematic
To: Peter Eisentraut <peter_e@gmx.net>, MauMau <maumau307@gmail.com>,
 Josh Berkus <josh@agliodbs.com>,
 "pgsql-docs@postgresql.org" <pgsql-docs@postgresql.org>
In-Reply-To: <53EBCCEA.3090604@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

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.=A0 The patch also addresses the problem that t=
he
>> archived file can get lost after power failure because it is not flushed
>> to disk.=A0=A0=A0 The patch consists of a program called pg_copy which c=
an be
>> used instead of cp/copy, and a doc fix to suggest using mv.=A0 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.=A0 What I have done is to use the cp/mv technique on=20
the database server and then rsync (through ssh) from each place=20
that needs it.=A0 That seems to me much less fragile than copying to=20
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=20
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.=A0 It's a nightmare to try to design anything to serve=20
multiple standbys without having the initial archive be local and=20
copying from that archive to the others.=A0 At least, if there is=20
some other good solution, I have yet to see it.

The above is regarding WAL file archiving -- I'm not putting down=20
streaming replication.=A0 Of course, what I would have *really* liked=20
is a WAL receiver that could write out normal-looking WAL files for=20
archiving purposes and pass through the WAL stream to a hot=20
standby.=A0 Last I checked (which was admittedly at least a couple=20
years back) there was no such utility, although I seem to remember=20
that Magnus had done some work that looked like it could be bent to=20
that end.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--=20
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs