Tom Lane wrote: > Tatsuo Ishii <is...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
