Re: Dividing progress/debug information in pg_standby, and stat before copy
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Dimitri Fontaine <dfontaine@hi-media.com>
Cc: Magnus Hagander <magnus@hagander.net>, Tom Lane <tgl@sss.pgh.pa.us>, Greg Smith <greg@2ndquadrant.com>, Selena Deckelmann <selenamarie@gmail.com>, Josh Berkus <josh@agliodbs.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Simon Riggs <simon@2ndquadrant.com>
Date: 2010-01-26T10:56:04Z
Lists: pgsql-hackers
Dimitri Fontaine wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> Yes. Just like with pg_standby. > > Hehe, I'm using walmgr.py from skytools instead, and this discussion > makes me think I'll continue doing so even if using SR, as they are > complementary solutions. > > In SR mode, the master continues to archive as usual, and the slave will > either take the WAL on a per-file basis from the restore_command or on > an per-LSN basis from the walreceiver and a live connection to the > master, right? Right. > Does it mean any working wal shipping setup (pitrtools, walmgr.py) will > continue working unchanged, or should we begin testing those and > scheduling adaptations to 9.0? They will continue to work as is, just leave standby_mode=off. But if you want to take advantage streaming replication, you'll have to switch it to 'on', and adapt the scripts to work with that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com