From: | "Gurjeet Singh" <gurjeet(at)singh(dot)im> |
---|---|
To: | "PG Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Minor edits to README.tuplock, and a question |
Date: | 2025-03-30 06:46:49 |
Message-ID: | D8TEDI0JBT4W.1219VGKNDNOTG@singh.im |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Please see attached a few minor edits to README.tuplock, which I feel
make an improvement over the current version.
Reading through that, though, I could not see a functional difference
between FOR NO KEY UPDATE and FOR KEY SHARE mode of locks. I understand
they are of different strength, exclusive vs. shared, but the way the
text (quoted below) describes them, they essentially both achieve the
same effect.
> SELECT FOR NO
> KEY UPDATE likewise obtains an exclusive lock, but only prevents tuple removal
> and modifications which might alter the tuple's key.
> SELECT FOR KEY SHARE obtains a shared lock which only
> prevents tuple removal and modifications of key fields.
Am I missing something?
<reads some more of the file>
Nevermind. Deciphering the conflict table below it makes clear the need
for similar looking locks, but with exclusive vs. shared mode
differences. I can't think of an improvement in the two sentences quoted
above, but perhaps others can think of something that helps the reader.
--
Best regards,
Gurjeet
http://Gurje.et
Attachment | Content-Type | Size |
---|---|---|
README.tuplock.diff | text/plain | 2.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2025-03-30 09:00:00 | The 026_overwrite_contrecord test might fail on extremely slow animals |
Previous Message | Tom Lane | 2025-03-30 04:04:52 | Re: Amcheck verification of GiST and GIN |