Re: TRUNCATE SERIALIZABLE and frozen COPY - Mailing list pgsql-hackers

On Fri, Nov 9, 2012 at 8:22 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Personally I think the behavior should be dictated by the *reader*.
>> The one doing the truncation may not know about the consistency
>> requirements of particular readers. Especially when you do the
>> truncate via pg_restore or some other generic tool. And indeed
>> different readers may have different consistency requirements.
>>
>> So I'd prefer if it were a GUC variable; readers that accept relaxed
>> consistency can set truncate_conflict=off
>
> I proposed something similar earlier, but Robert said he didn't like
> that. The way you've described it here makes more sense, whereas my
> parameter name made it seem more arbitrary. So I think that looks like
> the way to go.

Hmm, I don't remember saying I didn't like that.  Maybe I disliked
something about a particular proposed implementation?  Actually, I
don't really see the need for this to be customizable at all.  I have
to believe that there is vanishingly little application code that
would care about this change in semantics, so why not just change the
behavior and call it good?

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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company