Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Robert Haas wrote:
>> Furthermore, if you're wanting to use pg_standby, you might be
>> forgiven for thinking that you should set standby_mode = on; but in
>> fact that's exactly the wrong thing to do.
>
> Yeah, I think that's the main weakness of the name "standby_mode". It's
> pretty descriptive otherwise, we call that mode of operation "standby"
> everywhere, and always have.
>
> I'm not sure I dare to say this out loud after Simon's previous
> outburst, but removing or renaming pg_standby would help with that...
Well seen from here it's quite logical: when replaying WALs, you are
either in recovery mode and the server gets back as soon as possible, or
you are setting up a standby server, which will keep recovering until
told to stop doing so.
Now you have 2 main options for keeping your server in standby mode,
either the integrated one (standby_mode = on) or another one. If you
choose to have your standby state managed by an external tool, of course
the first thing to do is tell the server not to maintain itself the
state, so you switch standby_mode to off.
Then you can either use the included contrib pg_standby to achieve the
result, or some other solution, such as Skytools and walmgr.py or CMD
pitrtools.
The fact that the parameter and the external script share the name is a
hint that they're competing for solving the same problem (in different
ways).
Regards,
--
dim
