From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Andrew Sullivan <andrew(at)libertyrms(dot)info>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 2-phase commit |
Date: | 2003-09-26 18:05:36 |
Message-ID: | 25072.1064599536@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-26 18:07:46 | Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) |
Previous Message | Peter Eisentraut | 2003-09-26 17:58:21 | Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) |