Re: is sync rep stalled?
От | Simon Riggs |
---|---|
Тема | Re: is sync rep stalled? |
Дата | |
Msg-id | 1286279076.2025.1187.camel@ebony обсуждение исходный текст |
Ответ на | Re: is sync rep stalled? (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On Fri, 2010-10-01 at 19:48 +0900, Fujii Masao wrote: > My intention is to commit the core part of synchronous replication (which would > be used for every use cases) at first. Then we can implement the > feature for each > use case. I completely agree that we should commit the core part of sync rep, but the question is: what is that? We both have equally valid "cores". > I agree that 9.1 should support asynchronous standbys in the same mix, but this > seems to be extended feature rather than very core. That is trivial, so no need to exclude that. > I proposed to implement the "return-immediately" at first because it doesn't > require standby registration. But if many people think that the "wait-forever" > is the core rather than the "return-immediately", I'll follow them. We can > implement the "return-immediately" after that. I think its fair to say that many people don't like the specific form of standby registration that has been proposed. I really don't mind if it exists as an option, but it looks way too complex to me to manage for realistic systems. Wait-forever needs to be an option. Nobody actually will wait forever, so if people select it, they will need some form of clusterware to control it and I don't want to see people forced to use clusterware. If people do choose wait-forever, then we could also do standby registration automatically, to give them something to wait for. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: