Re: TRUNCATE SERIALIZABLE and frozen COPY

On 9 November 2012 14:01, Robert Haas <robertmhaas@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