Re: Exclusive lock for database rename

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Exclusive lock for database rename
Дата
Msg-id 200511031824.02124.peter_e@gmx.net
обсуждение исходный текст
Ответ на Exclusive lock for database rename  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut wrote:
> Someone wanted to rename a database while someone else was running a
> rather long pg_dump, so the rename had to wait, and everyone else had
> to wait for the rename because no new connections would be allowed.

As an auxiliary issue, why do the new connections have to wait in this
case?  The rename waits for the AccessShareLock of the dump to be
released, but meanwhile new connections should be able to get
AccessShareLocks of their own.  I see the following in pg_locks:
relation | database | transaction |  pid  |        mode         | granted
----------+----------+-------------+-------+---------------------+---------
[This is the "dump". (open transaction with select * from pg_database)]    1262 |        0 |             | 12296 |
AccessShareLock    | t         |          |      143076 | 12296 | ExclusiveLock       | t
 
[This is pg_locks.]   16839 |    24882 |             | 12296 | AccessShareLock     | t
[This is the rename.]         |          |      143078 | 12298 | ExclusiveLock       | t    1262 |        0 |
 | 12298 | AccessExclusiveLock | f
 
[This is a new connection.]         |          |      143079 | 12312 | ExclusiveLock       | t    1262 |        0 |
       | 12312 | AccessShareLock     | f
 

Why can't 12312 get the lock on 1262?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Rename the members of CommandDest enum so
Следующее
От: mark@mark.mielke.cc
Дата:
Сообщение: Re: Reducing the overhead of NUMERIC data