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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
