Re: Lock conflict behavior?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Lock conflict behavior?
Дата
Msg-id 6798.1229951538@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Lock conflict behavior?  (Tatsuo Ishii <ishii@postgresql.org>)
Ответы Re: Lock conflict behavior?  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
Список pgsql-hackers
Tatsuo Ishii <ishii@postgresql.org> writes:
> 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?

If we didn't do this, then a would-be acquirer of exclusive lock would
have a very serious problem with lock starvation: it might wait forever
in the face of a continuous stream of access-share lock requests.
        regards, tom lane


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

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: a small proposal for avoiding foot-shooting
Следующее
От: Bernd Helmle
Дата:
Сообщение: Re: WIP: Automatic view update rules