Simon Riggs <simon@2ndQuadrant.com> writes:
> On 9 November 2012 15:34, Kevin Grittner <kgrittn@mail.com> wrote:
>> If we're not talking about making conflicts with other transactions
>> behave just the same as an unqualified DELETE from a user
>> perspective, I'm not sure what the goal is, exactly.
> Reasonable question.
> My goal is to allow COPY to load frozen tuples without causing MVCC violations.
If that's the goal, I question why you're insisting on touching
TRUNCATE's behavior. We already have the principle that "TRUNCATE is
like DELETE except not concurrent-safe". Why not just invent a
non-concurrent-safe option to COPY that loads prefrozen tuples into a
new heap, and call it good? There will be visibility oddness from that
definition, sure, but AFAICS there will be visibility oddness from what
you're talking about too. You'll just have expended a very great deal
of effort to make the weirdness a bit different. Even if the TRUNCATE
part of it were perfectly clean, the "load prefrozen tuples" part won't
be --- so I'm not seeing the value of changing TRUNCATE.
regards, tom lane
