Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)
Дата
Msg-id 13526.1253640939@sss.pgh.pa.us
обсуждение исходный текст
Ответ на AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)  (Bryce Nesbitt <bryce2@obviously.com>)
Ответы Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)  (Bryce Nesbitt <bryce2@obviously.com>)
Список pgsql-sql
Bryce Nesbitt <bryce2@obviously.com> writes:
> 1) Why the AccessExclusiveLock on create table?

It has to install a trigger on the referenced table.  There has been
some discussion that maybe CREATE TRIGGER could take just ExclusiveLock
and not AccessExclusiveLock, but it hasn't been done yet; and I'm not
sure how much that would help you anyway.  It would only help if the
referenced table (contexts) is essentially read-only to the rest of
your workload, else it'll block anyhow.

> 2) Why is the foreign key check a heavy operation, since a new table
> will have zero foreign keys, it can't possibly violate the constraint yet.

It's not a heavy operation in that case.  The problem doubtless is that
it's backed up behind some other transaction that is sitting on a lock
on the contexts table.  And then everything else backs up behind it.

> 3) Other than eliminating dynamic table creation, how can this operation
> be altered?

Get rid of long-running transactions that hold locks on the contexts
table.
        regards, tom lane


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

Предыдущее
От: Bryce Nesbitt
Дата:
Сообщение: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks
Следующее
От: Bryce Nesbitt
Дата:
Сообщение: Re: AccessExclusiveLock on CREATE TABLE REFERENCES deadlocks (formatted better)