Re: Lock conflict behavior?
| От | Tom Lane |
|---|---|
| Тема | Re: Lock conflict behavior? |
| Дата | |
| Msg-id | 6798.1229951538@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Lock conflict behavior? (Tatsuo Ishii <ishii@postgresql.org>) |
| Ответы |
Re: Lock conflict behavior?
|
| Список | pgsql-hackers |
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.
regards, tom lane
В списке pgsql-hackers по дате отправления: