On Fri, Oct 21, 2016 at 1:38 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > Once we have that information, the foreign server can actively poll > the local server to get the status of transaction xid and resolves the > prepared transaction itself. It can go a step further and inform the > local server that it has resolved the transaction, so that the local > server can purge it from it's own state. It can remember the fate of > xid, which can be consulted by another foreign server if the local > server is down. If another transaction on the foreign server stumbles > on a transaction prepared (but not resolved) by the local server, > foreign server has two options - 1. consult the local server and > resolve 2. if the first options fails to get the status of xid or that > if that option is not workable, throw an error e.g. indoubt > transaction. There is probably more network traffic happening here. > Usually, the local server should be able to resolve the transaction > before any other transaction stumbles upon it. The overhead is > incurred only when necessary.
Yes, something like this could be done. It's pretty complicated, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
