On Mon, Jul 30, 2018 at 6:21 AM, Michael Paquier <mich...@paquier.xyz> wrote: > On Mon, Jul 30, 2018 at 05:53:54PM +0900, Kyotaro HORIGUCHI wrote: >> I feel that just being a database owner doesn't justify to cause >> this problem innocently. Catalog owner is also doubious but we >> can carefully configure the ownerships to avoid the problem since >> only superuser can change it. So I vote +1 for the revised patch. > > Thanks for the review. Yes that sucks that being just a database or a > schema owner allows such a user to take an exclusive lock on shared > catalogs. Please note that depending on the order of the relations, > authentication may or may not be blocked depending on what kind of locks > the second session takes.
Just as a general statement, I don't think we should, as part of a patch for the issue discussed on this thread, make any changes AT ALL to who has permission to perform which operations. We *certainly* should not back-patch such changes, but we really also should not make them on master unless they are discussed on a separate thread with a clear subject line and agreed by a clear consensus. This patch should only be about detecting cases where we lack permission earlier, before we try to acquire a lock. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
