On Thu, 7 Jul 2005, Stephen Frost wrote:
> * Andrew - Supernews (andrew+nonews@supernews.com) wrote:
> > On 2005-07-07, Stephen Frost <sfrost@snowman.net> wrote:
> > >
> > >> * truncate is not MVCC-safe.
> > >
> > > Erm, that's why it gets a stronger lock, so I don't really see what
> > > this has to do with it.
> >
> > It's not MVCC-safe even with the AccessExclusive lock; it damages snapshots
> > that were taken before the truncate operation but which don't have a lock
> > on the table yet. The only reason it doesn't break pg_dump is that the
> > first thing that pg_dump does is to take AccessShare locks on every table
> > that it's going to dump.
>
> This seems like something which should probably be fixed, but which is
> probably too late to fix for 8.1. Of course, if we could fix this then
> it seems like it would be possible for us to just change 'delete from x'
> to behave as truncate does now given appropriate conditions. I'm not as
Doesn't the lock difference between delete and truncate mean that suddenly
deletes on x may or may not block concurrent selects to x (depending on
whether it's a full table delete and whether x has delete triggers)? Or
are you thinking that after making it MVCC safe the lock could be
lessened?
With the current truncate lock, it seems bad to me for users who want to
do:
begin;delete from x;-- do inserts and other stuff to the now empty x
while still allowing access to x. Especially if whether or not you have
access depends on whether there are delete triggers on x.
