Re: Lock conflict behavior?

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Lock conflict behavior?
Дата
Msg-id 20081223.220746.35034168.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Список 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.

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


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

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Sync Rep: First Thoughts on Code