LOCK TABLE Permissions

Greetings,

We've run into a curious case and I'd like to solicit feedback
regarding a possible change to the access rights required to acquire
locks on a relation. Specifically, we have a process which normally
INSERTs into a table and another process which Exclusive locks that
same table in order to syncronize other processing. We then ran into
a case where we didn't actually want to INSERT but still wanted to
have the syncronization happen. Unfortunately, we don't allow
LOCK TABLE to acquire RowExclusive unless you have UPDATE, DELETE, or
TRUNCATE privileges.

My first impression is that the current code was just overly
simplistic regarding what level of permissions are required for a
given lock type and that it wasn't intentional to deny processes which
have INSERT privileges from acquiring RowExclusive (as they can do so
anyway using an actual INSERT). Therefore, I'd like to propose the
below simple 3-line patch to correct this.

Thoughts? Objections to back-patching?

Thanks,

Stephen

diff --git a/src/backend/commands/lockcmds.c b/src/backend/commands/lockcmds.c
new file mode 100644
index 49950d7..60f54c5 100644
*** a/src/backend/commands/lockcmds.c
--- b/src/backend/commands/lockcmds.c
*************** LockTableAclCheck(Oid reloid, LOCKMODE l
*** 174,179 ****
--- 174,182 ----
if (lockmode == AccessShareLock)
aclresult = pg_class_aclcheck(reloid, GetUserId(),
ACL_SELECT);
+ else if (lockmode == RowExclusiveLock)
+ aclresult = pg_class_aclcheck(reloid, GetUserId(),
+ ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE);
else
aclresult = pg_class_aclcheck(reloid, GetUserId(),
ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE);