Lock conflict behavior?

Поиск
Список
Период
Сортировка
Искать
От
Tatsuo Ishii
Тема
Lock conflict behavior?
Дата
Msg-id
20081222.171409.88492553.t-ishii@sraoss.co.jp
Список
Дерево обсуждения
Lock conflict behavior? Tatsuo Ishii <ishii@postgresql.org>
Re: Lock conflict behavior? Jeff Davis <pgsql@j-davis.com>
Re: Lock conflict behavior? Tatsuo Ishii <ishii@postgresql.org>
Re: Lock conflict behavior? Tatsuo Ishii <ishii@postgresql.org>
Re: Lock conflict behavior? Tom Lane <tgl@sss.pgh.pa.us>
Re: Lock conflict behavior? Jeff Davis <pgsql@j-davis.com>
Re: Lock conflict behavior? Bruce Momjian <bruce@momjian.us>
Re: Lock conflict behavior? Jeff Davis <pgsql@j-davis.com>
Re: Lock conflict behavior? Jeff Davis <pgsql@j-davis.com>
Re: Lock conflict behavior? Tom Lane <tgl@sss.pgh.pa.us>
Re: Lock conflict behavior? Jeff Davis <pgsql@j-davis.com>
Re: Lock conflict behavior? Tom Lane <tgl@sss.pgh.pa.us>
Re: Lock conflict behavior? Jan Urbański <j.urbanski@students.mimuw.edu.pl>
Hi,

I'm wondering if following behavior of PostgreSQL regarding lock
conflict is an expected one. Here's a scenario:

Session A:BEGIN;SELECT * FROM  pg_class limit 1; -- acquires access share lock

Session B:BEGIN;ALTER TABLE pg_class ....;	-- waits for acquiring access				   exclusive lock(wil fail anyway though)
Session C:SELECT * FROM pg_class...;	-- whatever query which needs				   to acces pg_class will be				   blocked, too bad...

I understand that B should wait for aquiring lock, but Should C wait
for?

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

В списке pgsql-hackers по дате отправления
От: Grzegorz Jaskiewicz
Дата:
Сообщение: affected rows count
От: Albe Laurenz
Дата:
FAQ