Re: Dividing progress/debug information in pg_standby, and stat before copy
Dimitri Fontaine <dfontaine@hi-media.com>
From: Dimitri Fontaine <dfontaine@hi-media.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.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:47:10Z
Lists: pgsql-hackers
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? (You explained it very clearly, so I hope I got it right, but some interrested readers might have skipped the other thread about it). 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? Regards, -- dim