Re: understand the pg locks in in an simple case
От
Laurenz Albe
Тема
Re: understand the pg locks in in an simple case
Дата
Msg-id
62a22ded39ba78e6410e2d2a2d41c1510606b029.camel@cybertec.at
Ответ на
Список
Дерево обсуждения
understand the pg locks in in an simple case Alex <zhihui.fan1213@gmail.com>
Re: understand the pg locks in in an simple case Laurenz Albe <laurenz.albe@cybertec.at>
Re: understand the pg locks in in an simple case Heikki Linnakangas <hlinnaka@iki.fi>
Re: understand the pg locks in in an simple case Alex <zhihui.fan1213@gmail.com>
Re: understand the pg locks in in an simple case Alex <zhihui.fan1213@gmail.com>
Alex wrote: > But when I check the pg_locks: session 1. I can see no tuple lock > there, when I check the session 2, I can see a > tuple(ExclusiveLock) is granted, but it is waiting for a > transactionid. > > since every tuple has txn information, so it is not hard to > implement it this way. but is there any benefits over the the > straight way? with the current implementation, what is the point > of tuple(ExclusiveLock) for session 2? From what I can tell the reason is that pg_locks reports the information from the shared memory locking table, and tuple locks are *not* maintained there, but in the "xmax" of the row itself. To see all tuple locks in pg_locks would require a sequential scan of all tables which have certain locks on them, which is not going to happen. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления