| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Dividing progress/debug information in pg_standby, and stat before copy |
| Date: | 2010-01-26 10:47:10 |
| Message-ID: | 871vhd87o1.fsf@hi-media-techno.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-01-26 10:55:04 | Re: Dividing progress/debug information in pg_standby, and stat before copy |
| Previous Message | Heikki Linnakangas | 2010-01-26 10:36:54 | Re: Dividing progress/debug information in pg_standby, and stat before copy |