Tom Lane wrote:
> [ Shrug... ] I remain of the opinion that 2PC is a solution in search
> of a problem, because it does not solve the single point of failure
> issue (just moves same from the database to the 2PC controller).
> But some people want it anyway, and they aren't going to be satisfied
> that we are an "enterprise grade" database until we can check off this
> particular bullet point. As long as the implementation doesn't impose
> any significant costs when not being used (which AFAICS Heikki's method
> doesn't), I think we gotta hold our noses and do it.
I thought the primary reason for having 2PC is to be able to participate
in a heterogenous transaction, e.g. with a non-Postgres database/other
types of resource managers? 2PC is mostly about how to make these
cross-RM transactions [appear] atomic. Redundancy is not covered by 2PC
protocol.
--
dave
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
