Re: Exposing the Xact commit order to the user

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