On 9 November 2012 14:01, Robert Haas <robertmh...@gmail.com> wrote: > I think the question that hasn't really been adequately answered is: > where and how are we going to track conflicts? Your previous patch > involved storing an XID in pg_class, but I think we both found that a > bit grotty - it'd probably need special handling for wraparound, and I > think we came up with some related cases that couldn't be handled in > the same way without adding a bunch more XIDs to various places. I > don't really like the idea of having XIDs floating around in the > system catalogs - it seems like a recipe for bugs, not to mention that > storing ephemeral data in a persistent table seems like a mismatch.
Yes, the xid only needs to be transient, not in pg_class. > What I've been wondering since this last came up is whether we could > use some variant of the SIREAD locks Kevin introduced for SSI to > handle this case - essentially have the transaction doing the TRUNCATE > make an entry in the lock table that will force a serialization > failure for any backend which accesses the table with a snapshot that > can't see the truncating transaction's XID. The lock table entry > would need some kind of deferred clean-up, so it doesn't go away until > the locker's XID precedes RecentGlobalXmin. Of course, an extra lock > table probe for every table access will be unacceptable from a > concurrency perspective, but we could probably optimize most of them > away by only checking the lock table if the pg_class row's own xmin is > new enough that the other backend's MVCC snapshot can't see it. A > recent update to pg_class doesn't imply the existing of a lock, but > the absence of any recent update to pg_class does imply that no lock > can exist. I think the xid should still live in relcache, per the patch, but should live in a transient place (and not pg_class). We need a fast lookup structure that is expandable to accommodate arbitrary numbers of truncates. Shared hash table, with some form of overflow mechanism. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers