On Thu, Jul 27, 2017 at 6:58 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On a technical level, I am pretty sure that it is not OK to call > AtEOXact_FDWXacts() from the sections of CommitTransaction, > AbortTransaction, and PrepareTransaction that are described as > "non-critical resource releasing". At that point, it's too late to > throw an error, and it is very difficult to imagine something that > involves a TCP connection to another machine not being subject to > error. You might say "well, we can just make sure that any problems > are reporting as a WARNING rather than an ERROR", but that's pretty > hard to guarantee; most backend code assumes it can ERROR, so anything > you call is a potential hazard. There is a second problem, too: any > code that runs from here is not interruptible. The user can hit ^C > all day and nothing will happen. That's a bad situation when you're > busy doing network I/O. I'm not exactly sure what the best thing to > do about this problem would be. >
The remote transaction can be committed/aborted only after the fate of the local transaction is decided. If we commit remote transaction and abort local transaction, that's not good. AtEOXact* functions are called immediately after that decision in post-commit/abort phase. So, if we want to commit/abort the remote transaction immediately it has to be done in post-commit/abort processing. Instead if we delegate that to the remote transaction resolved backend (introduced by the patches) the delay between local commit and remote commits depends upon when the resolve gets a chance to run and process those transactions. One could argue that that delay would anyway exist when post-commit/abort processing fails to resolve remote transaction. But given the real high availability these days, in most of the cases remote transaction will be resolved in the post-commit/abort phase. I think we should optimize for most common case. Your concern is still valid, that we shouldn't raise an error or do anything critical in post-commit/abort phase. So we should device a way to send COMMIT/ABORT prepared messages to the remote server in asynchronous fashion carefully avoiding errors. Recent changes to 2PC have improved performance in that area to a great extent. Relying on resolver backend to resolve remote transactions would erode that performance gain. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
