From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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-27 05:35:24 |
Message-ID: | 20030927133344.Y15218-100000@houston.familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2003-09-27 05:55:49 | Re: initdb failure (was Re: [GENERAL] sequence's plpgsql) |
Previous Message | Christopher Kings-Lynne | 2003-09-27 05:20:22 | Re: [HACKERS] Threads vs Processes |