From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Lock conflict behavior? |
Date: | 2008-12-22 08:14:09 |
Message-ID: | 20081222.171409.88492553.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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?
Also, it seems that an attacker could do a denial service attack if he
could open session A and B, since other users on session C or
following sessions will be blocked.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2008-12-22 08:44:23 | Re: a small proposal for avoiding foot-shooting |
Previous Message | Grzegorz Jaskiewicz | 2008-12-22 07:51:19 | affected rows count |