From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | xact.c state machine redesign |
Date: | 2004-09-15 17:34:01 |
Message-ID: | 5572.1095269641@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
After looking over the state machine in xact.c, I'm thinking of removing
the TBLOCK_SUBENDABORT_ALL and TBLOCK_SUBENDABORT_RELEASE states in
favor of having the ROLLBACK command mark the whole transaction state
stack similarly to what is now done for COMMIT. In detail this would
require adding a TBLOCK_ABORT_PENDING state to use at the top level,
and ROLLBACK would act thus:
* For each subtransaction level: if it's in SUBABORT state (ie, already
aborted) then shift it to SUBENDABORT state (giving permission to pop it
from the stack); otherwise mark it SUBABORT_PENDING.
* At the outer level: if it's in ABORT state then shift to ENDABORT,
otherwise mark it ABORT_PENDING.
In CommitTransactionCommand we would have the behaviors:
ABORT:
SUBABORT:
do nothing (same as now)
SUBENDABORT:
cleanup & pop
recursively examine parent
SUBABORT_PENDING:
abort subtransaction
cleanup & pop
recursively examine parent
ENDABORT:
cleanup
go to DEFAULT state
ABORT_PENDING:
abort transaction
cleanup
go to DEFAULT state
I'm also toying with handling ROLLBACK TO by marking all the levels
above the target as SUBENDABORT or SUBABORT_PENDING, and then marking
the target level with one of two new states, TBLOCK_SUBRESTART or
TBLOCK_SUBABORT_RESTART (the latter if it was already SUBABORT).
These would have the behaviors
TBLOCK_SUBRESTART:
abort subtransaction
cleanup & pop
start new subtransaction with same name
TBLOCK_SUBABORT_RESTART:
cleanup & pop
start new subtransaction with same name
This isn't any fewer states than we have now, but the states seem much
more clearly organized to me --- in particular, other than the RESTART
states there's full symmetry between outer-level and subtransaction
states. Also, this ensures that the planned state transitions are fully
marked out on the state stack before we start to do anything, which
I think is going to be more robust. AbortOutOfAnyTransaction is a bit of
a kluge and I don't really want to depend on it to implement ROLLBACK.
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-09-15 17:40:30 | Re: libpq and prepared statements progress for 8.0 |
Previous Message | Tom Lane | 2004-09-15 16:51:40 | Re: Problems with SPI memory management |