pgsql: Fix LOCK TABLE to eliminate the race condition that could make it
Log Message:
-----------
Fix LOCK TABLE to eliminate the race condition that could make it give weird
errors when tables are concurrently dropped. To do this we must take lock
on each relation before we check its privileges. The old code was trying
to do that the other way around, which is a bit pointless when there are lots
of other commands that lock relations before checking privileges. I did keep
it checking each relation's privilege before locking the next relation, which
is a detail that ALTER TABLE isn't too picky about.
Modified Files:
--------------
pgsql/src/backend/access/heap:
heapam.c (r1.274 -> r1.275)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/heapam.c?r1=1.274&r2=1.275)
pgsql/src/backend/commands:
lockcmds.c (r1.23 -> r1.24)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/lockcmds.c?r1=1.23&r2=1.24)
pgsql/src/include/access:
heapam.h (r1.141 -> r1.142)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/heapam.h?r1=1.141&r2=1.142)
On Tue, 2009-05-12 at 16:43 +0000, Tom Lane wrote:
Fix LOCK TABLE to eliminate the race condition that could make it give weird
errors when tables are concurrently dropped. To do this we must take lock
on each relation before we check its privileges. The old code was trying
to do that the other way around, which is a bit pointless when there are lots
of other commands that lock relations before checking privileges. I did keep
it checking each relation's privilege before locking the next relation, which
is a detail that ALTER TABLE isn't too picky about.
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Simon Riggs <simon@2ndquadrant.com> writes:
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?
That's been discussed before. I forget whether we decided it was a good
idea or not, but in any case it looks like a new feature not a bug fix.
regards, tom lane
On Tue, 2009-05-12 at 17:10 -0400, Tom Lane wrote:
Simon Riggs <simon@2ndquadrant.com> writes:
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?That's been discussed before. I forget whether we decided it was a good
idea or not, but in any case it looks like a new feature not a bug fix.
Agreed. I was just trying to think ahead to the implications and
difficulties of the LOCK and TRUNCATE changes and see if anything else
important emerged.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Tom Lane wrote:
Simon Riggs <simon@2ndquadrant.com> writes:
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?That's been discussed before. I forget whether we decided it was a good
idea or not, but in any case it looks like a new feature not a bug fix.
Is this a TODO?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Tue, 2009-06-02 at 14:33 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs <simon@2ndquadrant.com> writes:
If we're going to require cascaded permissions like this, would it make
sense to make GRANT cascade down the inheritance tree also?That's been discussed before. I forget whether we decided it was a good
idea or not, but in any case it looks like a new feature not a bug fix.Is this a TODO?
Yes.
Whatever was discussed before was prior to the changes to make TRUNCATE
and LOCK TABLE cascade. The cascading will fail without appropriate
permissions, so GRANT should work that way also, now.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support