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
|
Список | pgsql-admin |
Hi,
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."
> I dig another case more and found something interesting. it's actuallyNormal. That's the kind of lock you are waiting for when some other
> waiting for a lock of type transactionid. I ran the query below 3
transaction has touched the same rows for update that you are
attempting.
"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."
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 по дате отправления: