Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > Tom Lane wrote: >> We realized some time ago that it was a good idea to separate >> archive_mode (what to put in WAL) from archive_command (whether we are >> actually archiving right now). If we fail to apply that same principle >> to Hot Standby, I think we'll come to regret it.
> The recovery_connections GUC does that. If you enable it, the extra > information required for hot standby is written to the WAL, otherwise > it's not. No, driving it off recovery_connections is exactly NOT that. It's confusing the transport mechanism with the desired WAL contents. I maintain that this design is exactly isomorphic to our original PITR GUC design wherein what got written to WAL was determined by the current state of archive_command. We eventually realized that was a bad idea. So is this. As a concrete example, there is nothing logically wrong with driving a hot standby slave from WAL records shipped via old-style pg_standby. Or how about wanting to turn off recovery_connections temporarily, but not wanting the archived WAL to be unable to support HS? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers