Re: pg_archive_bypass

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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