Re: Issues with two-server Synch Rep
От | Josh Berkus |
---|---|
Тема | Re: Issues with two-server Synch Rep |
Дата | |
Msg-id | 4CBDC91A.3060707@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Issues with two-server Synch Rep (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Issues with two-server Synch Rep
|
Список | pgsql-hackers |
>> Absolutely. For a synch standby, you can't tolerate any standby delay >> at all. This means that anywhere from 1/4 to 3/4 of queries on the >> standby would be cancelled on any high-traffic OLTP server. Hence, >> "useless". > > Don't agree with your numbers there and you seem to be assuming no > workarounds would be in use. A different discussion, I think. The only viable workaround would be to delay vacuum on the master, no? > Adding the feedback channel looks trivial to me, once we've got the main > sync rep patch in. I'll handle that. OK. I thought it would be a major challenge. Ideally, we'd have some way to turn snapshot publication on or off; for a standby which was not receiving reads, we wouldn't need it. Maybe make it contingent on the status of hot_standby GUC? That would make sense. > For this reason, I've removed the "apply" mode from my patch, for now. I > want to get the simplest possible patch agreed and then add things > later. Um, ok. "apply" mode is still useful for users who are not running queries against the standby. Which many won't. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
В списке pgsql-hackers по дате отправления: