Re: Synchronous replication - patch status inquiry
От | Heikki Linnakangas |
---|---|
Тема | Re: Synchronous replication - patch status inquiry |
Дата | |
Msg-id | 4C7FB581.40802@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Synchronous replication - patch status inquiry (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Synchronous replication - patch status inquiry
|
Список | pgsql-hackers |
On 02/09/10 17:06, Simon Riggs wrote: > On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote: >> On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs<simon@2ndquadrant.com> wrote: >>> "All standbys" has no meaning without registration. It is not a question >>> that needs an answer. >> >> Tell that to the DBA. I bet s/he knows what "all standbys" means. >> The fact that the system doesn't know something doesn't make it >> unimportant. > >> I agree that we don't absolutely need standby registration for some >> really basic version of synchronous replication. But I think we'd be >> better off biting the bullet and adding it. I think that without it >> we're going to resort to a series of increasingly grotty and >> user-unfriendly hacks to make this work. > > I'm personally quite happy to have server registration. > > My interest is in ensuring we have master-controlled robustness, which > is so far being ignored because "we need simple". Refrring to above, we > are clearly quite willing to go beyond the most basic implementation, so > there's no further argument to exclude it for that reason. > > The implementation of master-controlled robustness is no more difficult > than the alternative. I understand what you're after, the idea of being able to set synchronization level on a per-transaction basis is cool. But I haven't seen a satisfactory design for it. I don't understand how it would work in practice. Even though it's cool, having different kinds of standbys connected is a more common scenario, and the design needs to accommodate that too. I'm all ears if you can sketch a design that can do that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: