On Sun, May 7, 2017 at 11:54 AM, Robert Haas <robertmhaas@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
