Re: 2-phase commit - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 2-phase commit
Date
Msg-id 25072.1064599536@sss.pgh.pa.us
Whole thread Raw
In response to Re: 2-phase commit  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: 2-phase commit  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: 2-phase commit  ("Marc G. Fournier" <scrappy@postgresql.org>)
Re: 2-phase commit  (Andrew Sullivan <andrew@libertyrms.info>)
Re: 2-phase commit  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Re: 2-phase commit  ("Hiroshi Inoue" <inoue@tpf.co.jp>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> You're not considering the possibility of a transient communication
>> failure.

> Can't the master re-send the request after a timeout?

Not "it can", but "it has to".  The master *must* keep hold of that
request forever (or until the slave responds, or until we reconfigure
the system not to consider that slave valid anymore).  Similarly, the
slave cannot forget the maybe-committed transaction on pain of not being
a valid slave anymore.  You can make this work, but the resource costs
are steep.  For instance, in Postgres, you don't get to truncate the WAL
log, for what could be a really really long time --- more disk space
than you wanted to spend on WAL anyway.  The locks held by the
maybe-committed transaction are another potentially unpleasant problem;
you can't release them, no matter what else they are blocking.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)
Next
From: Bruce Momjian
Date:
Subject: Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)