On 26/05/10 23:49, Jan Wieck wrote:
> In this implementation it wouldn't even matter if a transaction that was
> recorded actually never made it because it crashed before the WAL flush.
> It would be reported by this "commit order" feature, but there would be
> no traces of whatever it did to be found inside the DB, so that anomaly
> is harmless.
Hmm, I think it would also not matter if the reported commit order
doesn't match exactly the order of the commit records, as long as
there's no dependency between the two transactions.
What I'm after is that I think it would be enough to establish the
commit order using deferred triggers that are fired during pre-commit
processing. The trigger could get a number from a global sequence to
establish the commit order, and write it to a table. So you still need a
global sequence, but it's only needed once per commit.
(you have to handle deferred triggers that fire after the commit-order
trigger. perhaps by getting another number from the global sequence and
replacing the previous number with it)
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
