"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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
I would think we then would need both. archive_command with parameters
> 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.
I would like for it not to be an example, but a default value.
Something ready for production but with a very narrow use case.
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Tomas Vondra||Date: 2011-09-02 15:02:04|
|Subject: Re: PATCH: regular logging of checkpoint progress|
|Previous:||From: Andrew Dunstan||Date: 2011-09-02 14:43:05|
|Subject: Re: pg_upgrade automatic testing|