On Sun, May 7, 2017 at 11:54 AM, Robert Haas <robertmh...@gmail.com> wrote: > I'm having second thoughts based on some more experimentation I did > this morning. I'll update again once I've had a bit more time to poke > at it.
So the issue that I noticed here is that this problem really isn't confined to abort processing. If we ROLLBACK TO SAVEPOINT or ABORT TRANSACTION on an open connection, we really do not know what the state of that connection is until we get an acknowledgement that the command completed successfully. The patch handles that. However, the same is true if we're sending a SAVEPOINT or RELEASE SAVEPOINT command, and the patch that I posted doesn't do anything about those cases. I think it would be best to fix all transaction control commands in a symmetric manner. Concretely, I think we should replace the abort_cleanup_incomplete flag from my previous patch with a changing_xact_state flag and set that flag around all transaction state changes, clearing it when such changes have succeeded. On error, the flag remains set, so we know that the state of that connection is unknown and that we must close it (killing outer transaction levels as needed). Thoughts? -- 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
