]> granicus.if.org Git - postgresql/commit
Rethink the locking mechanisms used for CREATE/DROP/RENAME DATABASE.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 4 May 2006 16:07:29 +0000 (16:07 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 4 May 2006 16:07:29 +0000 (16:07 +0000)
commit52667d56a3b489e5645f069522631824b7ffc520
treefc53caf8cff281d944b0bcb1dd2b10f9e9e5b0c4
parentcb98e6fb8fd4f1ca955a85d5c0088e42e77a04f0
Rethink the locking mechanisms used for CREATE/DROP/RENAME DATABASE.
The former approach used ExclusiveLock on pg_database, which being a
cluster-wide lock meant only one of these operations could proceed at
a time; worse, it also blocked all incoming connections in ReverifyMyDatabase.
Now that we have LockSharedObject(), we can use locks of different types
applied to databases considered as objects.  This allows much more
flexible management of the interlocking: two CREATE DATABASEs need not
block each other, and need not block connections except to the template
database being used.  Similarly DROP DATABASE doesn't block unrelated
operations.  The locking used in flatfiles.c is also much narrower in
scope than before.  Per recent proposal.
doc/src/sgml/manage-ag.sgml
doc/src/sgml/ref/create_database.sgml
doc/src/sgml/ref/drop_database.sgml
src/backend/catalog/pg_shdepend.c
src/backend/commands/dbcommands.c
src/backend/commands/user.c
src/backend/storage/lmgr/lmgr.c
src/backend/utils/init/flatfiles.c
src/backend/utils/init/postinit.c