Re: Lock conflict behavior?

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