Canceling ROLLBACK statement - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Canceling ROLLBACK statement
Date
Msg-id CABOikdO5nQhHH+rScmLz09=XMOHeb-dd76U1u3RZdaSxFQpzaw@mail.gmail.com
Whole thread Raw
Responses Re: Canceling ROLLBACK statement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Tom Lane
Date:
Subject: Re: Canceling ROLLBACK statement