On 5/26/2010 5:12 PM, Heikki Linnakangas wrote:
> 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're not trying to derail this thread into yet another of our famous
"commit trigger" battles, are you?
>
> (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)
I could imagine a commit trigger as a special case that is fired AFTER
the trigger queue was shut down, so any operation that causes any
further triggers to fire would automatically abort the transaction. A
draconian, but reasonable restriction.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin