Re: recovery_connections cannot start - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: recovery_connections cannot start
Date
Msg-id 87mxwp9v4g.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: recovery_connections cannot start  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: recovery_connections cannot start  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
>>> Would it be possible to have "internal" commands there, as for example
>>> cd is in my shell, or test, or time, or some more ?
>>>
>>> That would allow for providing a portable /usr/bin/true command as far
>>> as archiving is concerned (say, pg_archive_bypass), and will allow for
>>> providing a default archiving command in the future, like "pg_archive_cp
>>> /location" or something.
>
> Separating wal_mode and archive_mode, as we recently discussed, might
> eliminate the need for this kludge, if archive_mode can then be made
> changeable without a restart.

I don't see my proposal as anything like a kludge at all. Internal
commands are hugely practical and here would allow for PostgreSQL to
provide basic portable archive and restore commands for simple cases,
providing the necessary guarantees and error management. 

Bypass the archiving is the most obvious flavor and in my mind shouldn't
require an external dependency. Make simple things simple and complex
one possible, as they say. PostgreSQL is one of the best software I've
ever worked with on this point, but the WAL management is still in its
infancy there: whatever you want to setup, it's complex.

Having "internal" commands will not remove any feature we already
have. Users would still be able to hook-in their own solutions for more
complex or demanding environments.

Please do explain in what sense that proposal is a kludge, I'd like to
be able to understand your viewpoint. Or maybe it's just either bad
wording on your part or bad reading on mine, nonetheless I felt like
having to give some more details here. That's an important point in my
mind. 

Dunno how much it's relevant for 9.0 though, maybe we'll be able to
reach a good enough solution without an internal bypass archive
command, but having (only this) one does not sound so complex that we
should not consider it at all.

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Wierd quirk of HS/SR, probably not fixable
Next
From: Heikki Linnakangas
Date:
Subject: Re: Wierd quirk of HS/SR, probably not fixable