Re: [HACKERS] Canceling ROLLBACK statement

2012-03-01 Thread Tom Lane
Pavan Deolasee  writes:
> If client is running a ROLLBACK statement and sends a statement cancel
> signal to the server and if the cancel signal gets processed after the
> transaction AbortTransaction() is completed, but before
> CleanupTransaction() is called, I think the server may try to ABORT the
> transaction again,

This should be okay.  If you can demonstrate a case where it causes
problems, that would be a bug to fix, but I don't think it's likely
to be anything fundamental.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Canceling ROLLBACK statement

2012-03-01 Thread Pavan Deolasee
Hi All,

While working on something in XC, I hit upon an assertion failure. While
this is in XC code, I believe there can be a way of reproducing this on
vanilla PostgreSQL as well. I could not do so even after several tries,
unless I add some code or run it through debugger. Here is the theory
anyways.

If client is running a ROLLBACK statement and sends a statement cancel
signal to the server and if the cancel signal gets processed after the
transaction AbortTransaction() is completed, but before
CleanupTransaction() is called, I think the server may try to ABORT the
transaction again, especially if it raises a ereport(ERROR) reporting
"canceling statement due to user request".  That results in server throwing
a warning "AbortTransaction while in ABORT state" and subsequently an
assertion failure in ProcArrayEndTransaction because proc->xid is not valid.

The reason I believe I am not able to reproduce this is because interrupts
are usually not processed between AbortTransaction and CleanupTransaction.
And when the server gets a chance to process the interrupts, its
DoingCommandRead and hence the cancel statement event is ignored. But its
not entirely unlikely that the server may get chance to process the
interrupt earlier. For example, if CleanupTransaction() calls elog() and
there are bunch of possible code paths where it can happen.

I am not sure if this is really an issue or if its worth fixing, but I
thought it will be good to share at the least.

Thanks,
Pavan
-- 
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com