On 23/09/10 18:08, Kevin Grittner wrote:
Less important than any of the above, but still significant in my
book, I fear that conflict recording and dangerous structure
detection could become very convoluted and fragile if we eliminate
this structure for committed transactions. Conflicts among specific
sets of transactions are the linchpin of this whole approach, and I
think that without an object to represent each one for the duration
for which it is significant is dangerous. Inferring information
from a variety of sources "feels" wrong to me.
Ok, so if we assume that we must keep all the information we have now,
let me try again with that requirement. My aim is still to put an upper
bound on the amount of shared memory required, regardless of the number
of committed but still interesting transactions.
Cahill's thesis mentions that the per-transaction information can be
kept in a table like this:
txnID beginTime commitTime inConf outConf
100 1000 1100 N Y
101 1000 1500 N N
102 1200 N/A Y N
That maps nicely to a SLRU table, truncated from the top as entries
become old enough, and appended to the end.
In addition to that, we need to keep track of locks held by each
transaction, in a finite amount of shared memory. For each predicate
lock, we need to store the lock tag, and the list of transactions
holding the lock. The list of transactions is where the problem is,
there is no limit on its size.
Conveniently, we already have a way of representing an arbitrary set of
transactions with a single integer: multi-transactions, in multixact.c.
Now, we have a little issue in that read-only transactions don't have
xids, and can't therefore be part of a multixid, but it could be used as
a model to implement something similar for virtual transaction ids.
Just a thought, not sure what the performance would be like or how much
work such a multixid-like structure would be to implement..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
