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