Hi, On Tue, May 02, 2017 at 11:13:58AM +0200, Magnus Hagander wrote: > Looks good to me as well. Applied, with only a minor further docs addition > saying that this is the default also on the high availability page.
I understand this is late, but a colleague alerted me to the following behaviour change: If you recover a server with default settings, it is our understanding that pg_isready will now return true immediately after the consistent state is reached and possibly well before recovery had actually ended (depending on the amount of outstanding wal). As hot standby works with log shipping, this is independent of the recovery.conf settings, i.e. even if standby_mode and primary_conninfo are not set. So if one was monitoring recovery like that before and expects pg_isready to only return true once the recovery is fully complete, this will now have to be adjusted. Also, if the recovered server is to be used for transactions, there will now be a window where the server accepts connections, but is in read-only mode.
Before, one had the make the concious choice to set hot_standby to get the behaviour, now it might be surprising to users, or maybe I'm overthinking this?
If that is indeed the case, maybe it should be mentioned more prominently in the documentation and/or get highlighted in the release notes?
Hmm. That's an interesting usecase.
I don't think it's a big enough one to revert this change, but it definitely makes sense to mention it under incompatible changes.
I wonder if what we really want here, at least long-term, is a flag for pg_isready that makes it wait for a server to actually go out of recovery?`Seems that a tool like the one mentioned here would have to do that -- it can be done now by doing pg_isready first and then psql to check the status, but it seems like it could be a worthwhile addition?
