Marc G. Fournier wrote: > On Fri, 26 Sep 2003, Tom Lane wrote: > >>Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
