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>)
Список pgsql-hackers
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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [HACKERS] WAL logging problem in 9.4.3?
Следующее
От: Alex
Дата:
Сообщение: Serialization questions