Marc G. Fournier wrote:
> On Fri, 26 Sep 2003, Tom Lane wrote:
>
>>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.
>
> Hrmmmm ... is there no way of having part of the protocol being a message
> sent back that its a valid/invalid slave? ie. slave has an uncommitted
> transaction, never hears back from master to actually do the commit, so
> after x-secs * y-retries any messages it does try to send to the master
> have a bit flag set to 'invalid'?
If I understand Andrew Sullivan's request, the purpose for integration
of 2-PC into PostgreSQL, is more for distributed query than
replication via an XA interface:
http://sybooks.sybase.com/onlinebooks/group-xsarc/xsg1111e/xatuxedo/@ebt-link;pt=61?target=%25N%13_446_START_RESTART_N%25
If that is the desire (XA-compatibility) then PostgreSQL might be
talking to an Oracle database or a BEA Tuxedo TPM acting as the
coordinator. So PostgreSQL won't have an opportunity to modify the
protocol in any meaningful way if it wishes to interoperate with
XA-based transaction managers.
If it is being used only amongst other PostgreSQL backends for
replication, then why not use one of the optimistic replication protocols:
http://www.inf.ethz.ch/personal/alonso/PAPERS/commit-fast.pdf
Mike Mascari
mascarm@mascari.com