On 11/17/2009 11:48 AM, Tom Lane wrote:
Peter Jones pjones@redhat.com writes:
Do they support rollbacks after commit? If they don't, they're not really as useful for this as they could be.
Rollback *after* commit? This must be some other usage of the term "commit" than is standard to database people.
So, I guess I should expand some more on what I'm saying.
The problem here is that normal database-like transactions don't help an upgrade much, because you don't really know whether you want to commit the changes until you've rebooted the machine and poked around for a bit.
Or, put another way, what you basically want is:
1 create an fs snapshot 2 do an upgrade 3 reboot machine 4 poke around 5 decide if it's good (6a) or bad (6b) 6 act on #5 a - remove snapshot b - abandon all changes after the snapshot
And if you're talking about implementing that with database-like semantics, then you want something non-traditional such as:
1 start transaction 2 upgrade 3 tentatively commit transaction 4 reboot machine 5 poke around 6 decide if it's good (6a) or bad (6b) 7 act on #6 a - fully commit transaction b - roll back
These obviously aren't the traditional semantics, hence I'm asking if it has semantics like that, because if it doesn't, then I don't really see Jeff's point.