Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
