Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > 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. Well, the inConf and outConf were later converted to pointers in Cahill's work, and our MVCC implementation doesn't let us use times quite that way -- we're using xmins and such, but I assume the point holds regardless of such differences. (I mostly mention it to avoid confusion for more casual followers of the thread.) > 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.. You're pointing toward some code I haven't yet laid eyes on, so it will probably take me a few days to really digest your suggestion and formulate an opinion. This is just to let you know I'm working on it. I really appreciate your attention to this. Thanks! -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
