Re: Lock conflict behavior?

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Lock conflict behavior?
Дата
Msg-id 20081223.184542.70202895.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Lock conflict behavior?  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Re: Lock conflict behavior?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> > 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Infrastructure changes for recovery (v8)