| 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: | Whole Thread | Raw Message | 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 |