Re: 2-phase commit

Christopher Kings-Lynne <chriskl@familyhealth.com.au>

From: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>, Andrew Sullivan <andrew@libertyrms.info>, <pgsql-hackers@postgresql.org>
Date: 2003-09-27T05:35:24Z
Lists: pgsql-hackers
> 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.

So, after 'n' seconds of waiting, we abandon the slave and the slave
abandons the master.

Such a condition is probably a fairly serious failure anyway, and
something that an admin would need to expect.  The admin would also need
to expect to allocate a heap of disk space for WAL.

Chris