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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan