Re: Two weeks to feature freeze - Mailing list pgsql-hackers

From Sailesh Krishnamurthy
Subject Re: Two weeks to feature freeze
Date
Msg-id bxy4r2hsbiw.fsf@datafix.CS.Berkeley.EDU
Whole thread Raw
In response to Re: Two weeks to feature freeze  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Two weeks to feature freeze
Re: Two weeks to feature freeze
List 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 by date:

Previous
From: Philip Yarra
Date:
Subject: Re: ECPG still having thread problems - follow-up
Next
From: Bruce Momjian
Date:
Subject: Re: $PostgreSQL$ for revision info