> > > Also, it seems that an attacker could do a denial service attack if he > > > could open session A and B, since other users on session C or > > > following sessions will be blocked. > > > > LOCK TABLE checks the permissions before attempting to acquire the lock, > > is there a reason that ALTER TABLE doesn't? > > Right. I think we should check the permissions first too. > > > Even if they don't have any rights to the table at all (not even > > SELECT), there are still other problems. For instance, the user could > > just wait for a long running query (or VACUUM) and issue the ALTER TABLE > > at that time. > > In the scenario I mentioned, even a new connection cannot be made to > the database since the backend need to initialize relcache by reading > system catlogs with access share lock at the very eary stage in > strating up.
Another concern is, two phase commit. If a 2PC transaction includes DDL, access share lock for pg_class is left. Someone comes with alter table pg_class and tries to hold an exclusive lock. After this all SELECT and autovacuum will stop because access share lock for pg_class cannot be aquired. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
