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? 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>
Tatsuo Ishii  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
Дата:
От: Bernd Helmle
Дата:
FAQ