Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really necessary?

Поиск
Список
Период
Сортировка
От Florian G. Pflug
Тема Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really necessary?
Дата
Msg-id 440CD9A9.50802@phlo.org
обсуждение исходный текст
Ответы Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really necessary?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Hi

I know that TRUNCATE needs to acquire an ACCESS EXCLUSIVE lock,
because it will remove the datafile on commit, and needs to ensure
that noone will be using it anymore by then. For a lot of applications
(at least mine) this is imposes problems. I'd like to use TRUNCATE
in a few places, not only to "clean out" the table, but also to prevent
others from inserting while I'm deleting everything (Think a cache table -
if I clear the cache, I don't want concurrent transactions to be able
to insert - but readers are not a problem, they still see the database
in their "old state", so seeing the cache in the "old state" is correct).

Now, I was thinking if TRUNCATE couldn't just let relfilenode in
pg_class point to a new datafile, and leave the old one in place.
TRUNCATE would still need a lock that prevents any write-access to
the table, but it wouldn't need to lock-out readers too.
VACUUM could then remove datafiles when it purges a record from pg_class.

I'm asking mainly out of curiosity - I though about this for a while now,
and couldn't come up with a reason why this wouldn't be possible.

greetings, Florian Pflug

В списке pgsql-general по дате отправления:

Предыдущее
От: "Harry Hehl"
Дата:
Сообщение: Sequencial scan instead of using index issue again
Следующее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: Is the "ACCESS EXCLUSIVE" lock for TRUNCATE really