Re: Exclusive lock for database rename - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Exclusive lock for database rename
Date
Msg-id 200511031824.02124.peter_e@gmx.net
Whole thread Raw
In response to Exclusive lock for database rename  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: Rename the members of CommandDest enum so
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Reducing the overhead of NUMERIC data