Re: Dividing progress/debug information in pg_standby, and stat before copy
От | Dimitri Fontaine |
---|---|
Тема | Re: Dividing progress/debug information in pg_standby, and stat before copy |
Дата | |
Msg-id | 871vhd87o1.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: Dividing progress/debug information in pg_standby, and stat before copy (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Dividing progress/debug information in pg_standby,
and stat before copy
|
Список | 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 по дате отправления: