Tom Lane wrote:
> 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.
See http://en.wikipedia.org/wiki/Readers-writers_problem
Jan
--
Jan Urbanski
GPG key ID: E583D7D2
ouden estin
