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  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Extensions, this time with a patch
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: WIP: extensible enums