"Kevin Grittner" <kevin.gritt...@wicourts.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 offers both. > 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. -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
