Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > On 14/06/10 13:39, Dimitri Fontaine wrote: >> I tend to consider it a bug that there's no known way under windows to >> use the same trick as under Unix by using '/usr/bin/true' as your >> archive command. And this Unix trick itself does feel like a hack. >> >> Also I'd very much like to be able to recommend (even if not change the >> official defaults) to setup wal_level to archive, archive_mode=on and >> archive_command=pg_archive_bypass, so that the day you have a HA budget >> ain't the day you're going to restart the server to enable the fault >> tolerance settings… > > That particular use case is better handled by making archive_mode changeable > on-the-fly. Now that we have wal_level as a separate GUC, it shouldn't be > too hard.
Ok. > I like internal commands as a solution in general, but it's still in search > of a problem.. What about /usr/bin/true, or a simple archive where you cp in a given location (which could happen to be a remote server thanks to unix network file systems or windows shares), etc. It seems to me those are existing problem that we solve poorly: let each user face the same pitfalls (error management). I also like Simon's approach to have options to internal commands too. What about this syntax : guc_name = "pg_internal function_name arg1 %r ... argn" Then function_name is any SQL callable function and you have the %x substitution still happening there for you. So you can mix hard-coded arguments (some path) and dynamic arguments. And you can script your commands in PL/WhateverU. It's more involved a patch, of course, but if we do that and provide some simple commands in -core, then most installations will only use that and stop bothering writing scripts to handle their simple cases. Which is what I'm after. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
