Exposing the Xact commit order to the user
in [PgSql]
|
Prev: [HACKERS] Exposing the Xact commit order to the user
Next: [HACKERS] Synchronization levels in SR
From: Jan Wieck on 26 May 2010 16:36 On 5/26/2010 4:11 PM, Dimitri Fontaine wrote: > So even ordering the txid and txid_snapshots with respect to WAL commit > time (LSN) won't be the whole story, for any given transaction > containing more than one event we also need to have them in order. I > know Jan didn't forget about it so it must either be in the proposal or > easily derived, too tired to recheck. No, that detail is actually not explained in the proposal. When applying all changes in transaction commit order, there is no need for a global sequence. A local counter per backend is sufficient because the total order of <xact-commit-order>, <local-xact-seq> yields a similarly agreeable order of actions. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 26 May 2010 16:49 On 5/26/2010 12:38 PM, Greg Stark wrote: > On Wed, May 26, 2010 at 5:10 PM, Jan Wieck <JanWieck(a)yahoo.com> wrote: >> ... but to answer that request, actually I don't even think we should be >> discussing API specifics. >> > > How about just API generalities? Like, where do you need this data, on > the master or on the slave? Would PGXC like it on the transaction > coordinator? > > What question do you need to answer, do you need to pull out sets of > commits in certain ranges or look up specific transaction ids and find > out when they committed? Or do you only need to answer which of two > transaction ids committed first? The question I want answered is "what was the order and xid of the next 0..n transactions, that committed after transaction X?" Preferably I would avoid scanning the entire available WAL just to get the next n xid's to process. The proposal assigned a unique serial number (file segment and position driven) to each xid and used that for the ordering as well as identification of the last known transaction. That is certainly a premature implementation detail. 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. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 26 May 2010 17:12 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 26 May 2010 17:13 On 5/26/2010 4:52 PM, Heikki Linnakangas wrote: > Ok, I think I understand it now. The commit order is enough, because > replaying the actions in the order "all actions of B, then all actions > of A" yields the same result. Precisely. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 26 May 2010 19:09
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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |