Re: ACCESS EXCLUSIVE LOCK

Поиск
Список
Период
Сортировка
От Andrew - Supernews
Тема Re: ACCESS EXCLUSIVE LOCK
Дата
Msg-id slrne0e20t.5md.andrew+nonews@atlantis.supernews.net
обсуждение исходный текст
Ответ на ACCESS EXCLUSIVE LOCK  (seth.m.green@gmail.com)
Список pgsql-hackers
On 2006-03-02, seth.m.green@gmail.com <seth.m.green@gmail.com> wrote:
> First of all, thank you very much. I changed TRUNCATE to DELETE FROM
> and my problem as been fixed.
>
> Is there any way to override that behavior? I know you can explicitly
> lock tables, can you explicitly unlock tables?

No.

> Just to be clear, once I run a TRUNCATE command inside an SP, that
> table that it acts upon will have an access exclusive lock on it until
> the SP is finished?

Until the transaction is finished, and since you can't commit from inside
a function, that means the lock will be held _at least_ until the end of
the SP.

This is necessary in order for other concurrent transactions not to get
incorrect results. (The difference between TRUNCATE and DELETE in this
case is that TRUNCATE gives the table a new, empty, heap and indexes,
deleting the old ones on commit; that means that it can't allow concurrent
access to the table since it is going to delete old tuples that might
otherwise still be visible to other transactions. DELETE on the other hand
simply marks the old tuples as dead; remember to vacuum as needed to clean
up.)

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [SQL] Interval subtracting
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Automatic free space map filling