Fujii Masao wrote:
> On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Fujii Masao wrote:
>>> On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
>>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>> Fujii Masao wrote:
>>>>> But if we fail in restoring the archived WAL file, "standby_mode = on"
>>>>> *always* tries to start streaming replication.
>>>> Hmm, somehow I thought it doesn't if you don't set primary_conninfo. I
>>>> think that's the way it should work, ie. if primary_conninfo is not set,
>>>> don't launch walreceiver but just keep trying to restore from the archive.
>>> Yeah, even if primary_conninfo is not given, the standby tries to invoke
>>> walreceiver by using the another connection settings (environment variables
>>> or defaults). This is intentional behavior, and would make the setup of SR
>>> easier. So I'd like to leave it be.
>> You could do primary_conninfo='' for that.
>>
>> Maybe we should have two options, "streaming_mode='on'" and
>> "primary_conninfo='...'".
>
> It looks better for me to extend the "standby_mode":
> For example, standby_mode = 'streaming' or 'archive'.
There's yet another mode that would be useful with hot standby: start up
the standby, but don't poll the archive and don't try to connect to the
master. Kind of 'paused' mode. Simon had functions to do that and more
in the original hot standby patch.
I've been thinking that this would work with just the three options we
have now:
standby_mode (true/false) controls whether the server keeps retrying
until trigger file is found (if trigger_file is set), rather than finish
recovery.
primary_conninfo (string) specifies a connection string to use to
connect to the master. If not given, don't try to connect.
restore_command (string) specifies a command to use to restore a file
from archive. If not given, don't try to restore files from archive.
I think this is pretty coherent and easy to explain, and makes all the
combinations restoring files from archive/streaming possible. But if
someone comes up with an even better scheme, I'm all ears.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com