Re: lock problem

Поиск
Список
Период
Сортировка
От Bèrto ëd Sèra
Тема Re: lock problem
Дата
Msg-id CAKwGa__-7ncap5sji9x0=3g5V=Fv1cpZYGO5bKDHgxeT6z9rzg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: lock problem  (Jerry Sievers <gsievers19@comcast.net>)
Ответы Re: lock problem  (Rural Hunter <ruralhunter@gmail.com>)
Список pgsql-admin
Hi,
 
> I dig another case more and found something interesting. it's actually
> waiting for a lock of type transactionid. I ran the query below 3

Normal.  That's the kind of lock you are waiting for when some other
transaction has touched the same rows for update that you are
attempting.

Record level locks are stored on the records themselves, so you won't see them explicitly mentioned in views like pg_locks:
"Although tuples are a lockable type of object, information about row-level locks is stored on disk, not in memory, and therefore row-level locks normally do not appear in this view. If a transaction is waiting for a row-level lock, it will usually appear in the view as waiting for the permanent transaction ID of the current holder of that row lock."
 
See http://www.postgresql.org/docs/9.1/static/explicit-locking.html

Bèrto
--
==============================
If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.

В списке pgsql-admin по дате отправления:

Предыдущее
От: Jerry Sievers
Дата:
Сообщение: Re: lock problem
Следующее
От: Rural Hunter
Дата:
Сообщение: Re: lock problem