On 9 November 2012 14:22, Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers