From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Alex <zhihui(dot)fan1213(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: understand the pg locks in in an simple case |
Date: | 2019-08-20 08:34:30 |
Message-ID: | 62a22ded39ba78e6410e2d2a2d41c1510606b029.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alex | 2019-08-20 08:47:37 | Serialization questions |
Previous Message | Kyotaro Horiguchi | 2019-08-20 08:17:57 | Re: [HACKERS] WAL logging problem in 9.4.3? |