Re: Dividing progress/debug information in pg_standby, and stat before copy - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Dividing progress/debug information in pg_standby, and stat before copy
Date
Msg-id 871vhd87o1.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Dividing progress/debug information in pg_standby, and stat before copy  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Dividing progress/debug information in pg_standby, and stat before copy  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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
threadabout 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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Next
From: Simon Riggs
Date:
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy