On Fri, Apr 23, 2010 at 2:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
You're all confused about what the different GUCs actually do. Which is probably not a good sign for their usability. But yeah, that's one of the things that concerned me, too. If you turn off max_wal_senders, it doesn't just make it so that no WAL senders can connect: it actually changes what gets WAL-logged. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers