Re: Hot Standby query cancellation and Streaming Replication integration
От | Bruce Momjian |
---|---|
Тема | Re: Hot Standby query cancellation and Streaming Replication integration |
Дата | |
Msg-id | 201002262148.o1QLmch23807@momjian.us обсуждение исходный текст |
Ответ на | Re: Hot Standby query cancellation and Streaming Replication integration (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: Hot Standby query cancellation and Streaming Replication integration
Re: Hot Standby query cancellation and Streaming Replication integration |
Список | pgsql-hackers |
Dimitri Fontaine wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > Well, as Heikki said, a stop-and-go WAL management approach could deal > > with that use-case. What I'm concerned about here is the complexity, > > reliability, maintainability of trying to interlock WAL application with > > slave queries in any sort of fine-grained fashion. > > Some admin functions for Hot Standby were removed from the path to ease > its integration, there was a pause() and resume() feature. > > I think that offering this explicit control to the user would allow them > to choose between HA setup and reporting setup easily enough: just pause > the replay when running the reporting, resume it to get fresh data > again. If you don't pause, any query can get killed, replay is the > priority. 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. -- 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 по дате отправления: