Skip site navigation (1) Skip section navigation (2)

Re: postgresql.conf archive_command example

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: postgresql.conf archive_command example
Date: 2011-09-02 17:00:37
Message-ID: CA+TgmobFuMj8KQEKGmd+McCs+0QDxzS7PyOM7fA3wpzGWfX=fA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Sep 2, 2011 at 10:34 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> I'm also wondering if providing some shell script examples of a
>>>> fault-tolerant script to handle archiving would be useful.
>>>
>>> I think it would.
>>
>> My usual advice is to avoid having to write one if possible,
>> because it's more complex than it looks.  What about recommending
>> existing solutions, such as walmgr from Skytools?
>>
>> Even better, what about including a default archiving tool, that
>> could be either another script in bin/ or rather an internal
>> command. The default would accept a location as argument, for
>> simple needs you mount a remote filesystem and there you go.  If
>> you need something more complex, you still can provide it
>> yourself.
>
> In a green field I might argue for having an archvie_directory GUC
> instead of archive_command.  As it stands, it might be a really good
> idea to provide a pg_archiveto executable which takes as arguments a
> directory path and the arguments passed to the archive script.  With
> a little extra effort, the executable could check for some file
> which would specify what host and path should be writing archives
> there, to avoid problems with copied database directories
> accidentally writing to the same location as the source.
>
> Such an executable seems like minimal effort compared to the
> problems it would solve.
>
> If there's an existing tool with appropriate licensing which is
> sufficiently portable and reliable, all the better -- let's ship it
> and use that for our example archive_command.

Another thought I have here is to wonder whether we should change
something on the server side so that we don't NEED such a complicated
archive_command.  I mean, copying a file to a directory somewhere is
not fundamentally a complex operation.  Nor is using ssh to copy it to
another machine.  The fact that archive_commands need to be so complex
seems like a usability defect.  The consensus seems to be that just
using something like 'cp' for your archive command won't work out
well, but maybe instead of shipping a more complicated script we
should be trying to eliminate (or at least reduce) the need for a more
complicated script.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-09-02 17:09:42
Subject: Re: PATCH: regular logging of checkpoint progress
Previous:From: Alvaro HerreraDate: 2011-09-02 16:53:12
Subject: Re: [COMMITTERS] pgsql: Remove "fmgr.h" include in cube contrib --- caused crash on a Ge

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group