On 11/17/2009 11:48 AM, Tom Lane wrote:
> Peter Jones <pjones@xxxxxxxxxx> 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.
--
Peter
If you're not part of the solution, then you're part of the precipitate.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
