Re: TRUNCATE locking problem

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Joe Maldonado <jmaldonado(at)webehosting(dot)biz>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: TRUNCATE locking problem
Date: 2005-07-18 14:15:21
Message-ID: 20050718141521.GX24207@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

* Joe Maldonado (jmaldonado(at)webehosting(dot)biz) wrote:
> It seems that TRUNCATE is first posting a lock on the table and then
> waiting for other transactions to finish before truncating the table
> thus blocking all other operations.
>
> Is this what is actually going on or am I missing something else? and is
> there a way to prevent this condition from happening?

TRUNCATE isn't MVCC-safe, for one thing. For another, yes, it uses a
much heavier lock on the table. If you don't want to use a heavy lock
on the table then you'll need to delete from *;. I've got a similar
setup to you and was looking at using truncate for it but I've been
starting to think just interjecting a vacuum in the middle might be
better. ie:

Instead of using:
truncate x;
insert into x;

Doing:
delete from x;
vacuum x;
insert into x;

I'm not really sure which would be faster, so I'm kind of curious about
that. In my case people are rarely using the table at the same time
they'd be truncating/delete'ing it (the UI doesn't actually allow it) so
the total time may be close between the two. For your case that might
not be true since the vacuum might not be able to do much due to the
other select's, which means the table ends up being double the size due
to the old tuples, etc. If someone else has a better solution I'd love
to hear it.

Thanks,

Stephen

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-07-18 14:22:36 Re: TRUNCATE locking problem
Previous Message John DeSoi 2005-07-18 13:57:44 Re: How to find the number of rows deleted