Re: Lock conflict behavior?
От
Tom Lane
Тема
Re: Lock conflict behavior?
Дата
Msg-id
6798.1229951538@sss.pgh.pa.us
Ответ на
Lock conflict behavior? (Tatsuo Ishii)
Список
Дерево обсуждения
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 по дате отправления