From: "Martijn van Oosterhout" <[EMAIL PROTECTED]>
> Well, actually, the problem appears to be that people want to be able to
> roll back each individual statement without killing the parent
transaction,
> and they want to make this the default behaviour. This takes it out of the
> "never used" category to "everybody does it" category.
Ok. Now I am confused. I thought that a nested transaction would involve
two features:
1: The ability to incrimentally commit/rollback changes, i.e. at certain
points in the transaction have a sub-commit.
2: The ability to have a transaction within another transaction with
transactional visibility rules applying within the transaction tree.
What exactly do you mean by roll back individual statements? What exactly
would be the default behavior?
> There is
> a bit of discussion on how to actually store that info in a way that can
be
> checked efficiently because remember, visibility needs to be checked for
> every tuple on every sequential scan in every process that runs
subsequently,
> so it needs to be *fast*.
Then you might have to have an array of "related transactions" which are
also visible for each thransaction, sort of like a tree with bidirectional
links. Unfortunately I can imagine this being a source of subtle, hard to
troubleshoot bugs. Something like
_x_id, _x_status, related_x_id[], child_x_id[], so that a rollback can
rollback all child_x_id's without touching the other transactions which are
parents, cousins, etc. but visible.
Best Wishes,
Chris Travers
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
