Re: Re: [COMMITTERS] pgsql: Don't use "cp -i" in the example WAL archive_command. - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Re: [COMMITTERS] pgsql: Don't use "cp -i" in the example WAL archive_command.
Date
Msg-id 201106181328.p5IDSmR18887@momjian.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Don't use "cp -i" in the example WAL archive_command.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Thom Brown <thom@linux.com> writes:
> > On 18 June 2011 04:13, Bruce Momjian <bruce@momjian.us> wrote:
> >> I tested on FreeBSD 7.4 and saw a 1 error return:
> 
> > And on a Mac (so through Darwin 10.7.0 a BSD version too):
> 
> Yeah, see yesterday's discussion on pgsql-admin.  I think the behavior
> with the error return may be a BSD-ism.  In any case, GNU cp does *not*
> do what we want, and that accounts for a sufficiently large fraction of
> machines in the field that I think it's just unsafe to suggest using
> "cp -i" so prominently.  There are too many people who'll just copy and
> paste the first example provided, especially if the warning to test it
> is buried several paragraphs later.

Agreed.  Even if we could decide whether we want an existing file to
cause cp to fail or succeed, the bigger problem is that 'test ! -f $FILE
&& cp' and 'cp -i' often don't do the same thing, to the point where it
doesn't even seem worth mentioning the idea of using 'cp -i' at all.

I frankly don't think most users are competent enough to be able to test
their cp -i command, end even if they are, that script might migrate to
a machine that handles cp -i differently.

I think we should just document the test ! -f version and be done with
it, and maybe mention cp -i as non-portable.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: plpgsql performance - SearchCatCache issue
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade using appname to lock out otherusers