On 08/11/2014 12:49 PM, Tom Lane wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> Josh Berkus <josh@agliodbs.com> wrote:
>>> Yeah, realistically, I think we need to start supplying a script or two
>>> in /contrib and referencing that.� I'm not sure how to make it work for
>>> the Windows users though.
>
>> That might work.� We should do something, though.� The example we
>> give in the docs is not production quality IMO, and is something of
>> an embarrassment.
>
> Well, it's not really intended to be production grade, and I think the
> docs say so (perhaps not emphatically enough).
Thing is, if we supply a sample command in the docs ... even if it's
preceeded by ***DO NOT USE WILL EAT YOUR SERVER*** ... people will still
copy-and-paste it, and then put it into production.
> The problem with such things as sample scripts is that it might get hard
> for people to tell the difference between barnacles (like email ;-))
> and properties that they'd better preserve in any custom script.
> The documentation is primarily trying to make the point that the archive
> action must not overwrite any existing file (which is such a property)
> and that's why it has the test ! -f. It doesn't really address the
> question of appropriate error handling, which is what Josh is on about.
I'm suggesting that we've established that there is no one-liner which
will not cause real problems for users who copy it. Given that, we
should not supply a one-liner, even as an example; we should supply some
sample scripts, and a reference in the docs:
"Please look at /share/archiving-scripts/ for some sample shell scripts
for archiving, or use a project like WAL-E, Barman, or OmniPITR."
The alternative is to supply a C utility ourselves for log copying, but
I think the presence of multiple archiving utilities is a good argument
that it's not possible for any given utility to cover more than 30% of
use-cases.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com