Re: [GENERAL] LOCK TABLE permission requirements
* Josh Kupershmidt: > On Wed, Jun 29, 2011 at 7:48 AM, Florian Weimer wrote: >> I've been looking around in the 9.0 documentation, but couldn't find the >> permission requirements for LOCK TABLE (in particular, LOCK TABLE IN >> SHARE MODE). From the source, you need at least one of UPDATE, DELETE >> or TRUNCATE. >> >> Is there a reason why the INSERT privilege is not sufficient for LOCK >> TABLE, or is this just an oversight? > > The comments on this thread outline some reasons the permissions for > LOCK TABLE are setup the way they are: > http://archives.postgresql.org/pgsql-hackers/2010-11/msg01819.php > > Basically, if you have UPDATE, DELETE, or TRUNCATE privileges you can > potentially lock out competing sessions on a table, similar to what > some forms of LOCK TABLE would do; just having INSERT privileges > doesn't necessarily give you that power. This makes sense, thanks. Doesn't REFERENCES have the same potential? Then it could be added to the list. In my pre-9.1 world, I need to acquire a table lock to avoid incorrectly serialized transactions. The application is only doing SELECTs and INSERTs, so I don't want to grant it UPDATE privileges, but REFERENCES would be fine. Right now, I'm using a separate, empty table and lock that, but that's a bit of a kludge. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] LOCK TABLE permission requirements
On Wed, Jun 29, 2011 at 7:48 AM, Florian Weimer wrote: > I've been looking around in the 9.0 documentation, but couldn't find the > permission requirements for LOCK TABLE (in particular, LOCK TABLE IN > SHARE MODE). From the source, you need at least one of UPDATE, DELETE > or TRUNCATE. > > Is there a reason why the INSERT privilege is not sufficient for LOCK > TABLE, or is this just an oversight? The comments on this thread outline some reasons the permissions for LOCK TABLE are setup the way they are: http://archives.postgresql.org/pgsql-hackers/2010-11/msg01819.php Basically, if you have UPDATE, DELETE, or TRUNCATE privileges you can potentially lock out competing sessions on a table, similar to what some forms of LOCK TABLE would do; just having INSERT privileges doesn't necessarily give you that power. Josh -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] LOCK TABLE permission requirements
I've been looking around in the 9.0 documentation, but couldn't find the permission requirements for LOCK TABLE (in particular, LOCK TABLE IN SHARE MODE). From the source, you need at least one of UPDATE, DELETE or TRUNCATE. Is there a reason why the INSERT privilege is not sufficient for LOCK TABLE, or is this just an oversight? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general