Skip site navigation (1) Skip section navigation (2)

Re: Strange locking choices in pg_shdepend.c

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Strange locking choices in pg_shdepend.c
Date: 2008-01-21 22:31:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> I came across some rather strange choices of lock levels in pg_shdepend.c.
> Why does shdepDropOwned() take AccessExclusiveLock on pg_shdepend?
> Seems like RowExclusiveLock should be sufficient.  If it isn't
> sufficient, I wonder whether the other functions in here are taking
> strong enough locks.

Hmm, I can't recall nor deduce any reason for that.  Perhaps the
intention was to protect against itself; but I think this should only
matter if we're dropping the same role concurrently (otherwise the
to-be-dropped objects would be disjoint sets, so it doesn't matter),
which should be already protected by the lock on the role itself.

Hmm, unless revoking privileges concurrently, for two different users on
the same object could cause a problem?  I don't see us grabbing a lock
on the object itself -- does this matter?

> It's probably not a good idea to have shdepReassignOwned() take only
> AccessShareLock on pg_shdepend.  Even though the function itself
> merely reads the table, it is going to call functions that will take
> RowExclusiveLock, meaning that we're setting ourselves up for potential
> deadlock failures due to lock-upgrade.  It'd be safer (and faster too)
> to just hold RowExclusiveLock through the whole operation.

Huh, correct.  I think this was just an oversight.

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-01-21 23:01:04
Subject: Thoughts about bug #3883
Previous:From: Alvaro HerreraDate: 2008-01-21 22:13:54
Subject: Re: [GENERAL] setof record "out" syntax and returning records

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group