From: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Lock conflict behavior? |
Date: | 2008-12-22 13:55:00 |
Message-ID: | 494F9C34.7040400@students.mimuw.edu.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Tatsuo Ishii <ishii(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Tolley | 2008-12-22 14:15:58 | Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets |
Previous Message | Bernd Helmle | 2008-12-22 13:53:19 | Re: WIP: Automatic view update rules |