On 9 November 2012 14:22, Kevin Grittner <kgrittn@mail.com> wrote:
> Robert Haas wrote:
>
>> 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.
>
> It seems to me that the goal would be to make this semantically
> idential to the behavior users would see if an unqualified DELETE
> were run against the table rather than a TRUNCATE.
Unqualified DELETE already runs that way. TRUNCATE is a different
command for a reason. Making TRUNCATE like something we already have
seems not very useful to me, not least because it breaks existing
applications.
> This seems like a subset of the issues which one might want to
> address by making DDL statement behave in a more strictly MVCC
> fashion. Does it make sense to pick those off one at a time, or
> should something like this be done only in the context of an overall
> plan to deal with all of it?
TRUNCATE is not DDL, plus I have no interest in this other than
speeding up COPY.
Scope creep just kills features.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
