Re: Two weeks to feature freeze
От | Sailesh Krishnamurthy |
---|---|
Тема | Re: Two weeks to feature freeze |
Дата | |
Msg-id | bxy4r2hsbiw.fsf@datafix.CS.Berkeley.EDU обсуждение исходный текст |
Ответ на | Re: Two weeks to feature freeze (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Two weeks to feature freeze
Re: Two weeks to feature freeze |
Список | pgsql-hackers |
>>>>> "Bruce" == Bruce Momjian <pgman@candle.pha.pa.us> writes: Bruce> Tom Lane wrote: >> Bruce Momjian <pgman@candle.pha.pa.us> writes: > The question >> was whether 2PC is useful. The question wasn't if an > >> unreliable 2PC was useful. >> >> My question is whether there is such a thingas reliable 2PC. >> I sure don't see how you build that. Bruce> Other databases use 2PC --- are you saying none of them are Bruce> reliable? And they use them for both federated read/write (what you refer to as distributed access through dblink) and for clustered configurations. I'm not sure if I understand Tom's beef - I think he is concerned about what happens if a subordinate does not respond to a prepare message. I would assume that the co-ordinator would not let the commit go through until it has received confirmations from every subordinate. The application's commit will remain blocked against the co-ordinator when this takes place. That said, I agree that 2PC (and variants) is rather heavy weight when in widely distributed configurations. (Although I guess in practice, many people use Presumed Abort and not vanilla 2PC as PA results in fewer log flushes for read-only transactions.) -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
В списке pgsql-hackers по дате отправления: