Re: Lock conflict behavior?

> > > 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