From: John Rouillard <rouilj@renesys.com>
To: Tim <elatllat@gmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: archive_command vs. cp -i
Date: Fri, 17 Jun 2011 17:26:50 +0000
Message-ID: <20110617172650.GG26732@renesys.com> (raw)
In-Reply-To: <BANLkTinjAm0nQ8Kosv7Q1u4=5UZj4jcFHQ@mail.gmail.com>
References: <20110617084057.238070@gmx.net>
<4DFB3B68020000250003E7EA@gw.wicourts.gov>
<BANLkTinjAm0nQ8Kosv7Q1u4=5UZj4jcFHQ@mail.gmail.com>
Hi all:
Corrected the top posting.
On Fri, Jun 17, 2011 at 12:55:07PM -0400, Tim wrote:
> On Fri, Jun 17, 2011 at 12:32 PM, Kevin Grittner
> Kevin.Grittner@wicourts.gov> wrote:
> > "Martin Münstermann"<mmuenst@gmx.de> wrote:
> > > while setting up a new linux postgresql server, I checked my
> > > archive_command. I noticed that the usual "cp -i f1 f2 <
> > > /dev/null" did NOT as expected: It did not overwrite the file
> > > (PASS), but it returned zero (FAIL, should return error).
> > >
> > > This could be reproduced on CentOS 5.6, RHEL4, and Ubuntu 10.04.
> > I've confirmed on SLES 10 and Ubuntu 9, too.
Not really surprising since choosing to not copy a file isn't really
an indication of an error when copying a file so...
I get the same result (0 exit status) on solaris 8 and solaris 10 with
/bin/cp. I wonder what platform the example worked on.
> > > Should the BACKUP-ARCHIVING-WAL doc be changed?
> >
> > I think so. Given the wide variety of platforms on which the
> > example could silently cause data loss, I *really* don't think we
> > want that in our docs. Someone could blithely copy it into
> > production without testing and not know they had it wrong until a
> > backup failed to restore.
For what it's worth I strongly agree.
> Technically the documentation covers its self by saying:
> "This is an example, not a recommendation, and might not work on all
> platforms."
> What would be nice is if the documentation could be made more useful by
> providing some more complex example scripts.
> What do our readers use for WAL archiving?
'test ! -f /var/bak/pgsql/%f && cp %p /var/bak/pgsql/%f'
Which does have a slight race condition as the output file could be
created between the test finishing and the cp starting. But the only
way that is likely to happen is if postgresql tried to run two
identical archive commands in parallel, and I think I would have other
issues if that was happening.
The following may be safer if you are using a shell with noclobber, or
it may not be. Depends on the race conditions in how the shell
implements the noclobber code.
'sh -c "set -o noclobber; cat %p > /var/bak/pgsql/%f"'
--
-- rouilj
John Rouillard System Administrator Renesys Corporation
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: rouilj@renesys.com, elatllat@gmail.com
Subject: Re: archive_command vs. cp -i
In-Reply-To: <20110617172650.GG26732@renesys.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox