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