Re: Hot Standby query cancellation and Streaming Replication integration
От | Bruce Momjian |
---|---|
Тема | Re: Hot Standby query cancellation and Streaming Replication integration |
Дата | |
Msg-id | 201002270036.o1R0avG03960@momjian.us обсуждение исходный текст |
Ответ на | Re: Hot Standby query cancellation and Streaming Replication integration (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Hot Standby query cancellation and Streaming Replication
integration
|
Список | pgsql-hackers |
Greg Smith wrote: > Bruce Momjian wrote: > > Doesn't the system already adjust the delay based on the length of slave > > transactions, e.g. max_standby_delay. It seems there is no need for a > > user switch --- just max_standby_delay really high. > > > > The first issue is that you're basically saying "I don't care about high > availability anymore" when you increase max_standby_delay to a high > value. Want to offload an 8 hour long batch report every day to the > standby? You can do it with max_standby_delay=8 hours. But the day > your master crashes 7 hours into that, you're in for a long wait before > your standby is available while it replays all the queued up segments. > Your 'hot standby' has actually turned into the old form of 'cold > standby' just when you need it to be responsive. Well, I think the choice is either you delay vacuum on the master for 8 hours or pile up 8 hours of WAL files on the slave, and delay application, and make recovery much slower. It is not clear to me which option a user would prefer because the bloat on the master might be permanent. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
В списке pgsql-hackers по дате отправления: