From: | Alex <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | understand the pg locks in in an simple case |
Date: | 2019-08-20 07:23:43 |
Message-ID: | CAKU4AWqdbsjGP0WNWODu0ha8FM9Xpn9iFVCZbnxQvRs5mX32Qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have troubles to understand the pg lock in the following simple
situation.
Session 1:
begin; update t set a = 1 where a = 10;
Session 2:
begin; update t set a = 2 where a = 10;
They update the same row and session 2 is blocked by session 1 without
surprise.
The pretty straight implementation is:
Session 1 lock the the *tuple (ExclusiveLock)* mode.
when session 2 lock it in exclusive mode, it is blocked.
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 | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2019-08-20 08:17:57 | Re: [HACKERS] WAL logging problem in 9.4.3? |
Previous Message | Amit Kapila | 2019-08-20 06:42:28 | Re: POC: Cleaning up orphaned files using undo logs |