KEY UPDATE / UPDATE / NO KEY UPDATE distinction vs. README.tuplock

From: Florian Pflug <fgp(at)phlo(dot)org>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: KEY UPDATE / UPDATE / NO KEY UPDATE distinction vs. README.tuplock
Date: 2014-10-23 14:37:46
Message-ID: 3FBFACF5-B423-42EA-A2F9-D6281545A1FE@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

It seems that README.tuplock never got updated when the KEY SHARE patch's
lock level were changed from being KEY UPDATE / UPDATE / SHARE / KEY SHARE
to UPDATE / NO KEY UPDATE / SHARE / KEY SHARE.

Thus, as it stands, that file implies that SELECT FOR UPDATE obtains a
weaker lock than an actual UPDATE might take (if that update modifies key
columns) -- according to README.tuplock, the former doesn't conflict with
KEY SHARE while the actual UPDATE would.

But this isn't actually the case in the committed version of the patch -
one now needs to explicitly request that weaker lock level with SELECT FOR
NO KEY UPDATE.

The attached patch updated README.tuplock accordingly.

best regards,
Florian Pflug

Attachment Content-Type Size
README.tuplock.patch application/octet-stream 3.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-10-23 14:39:58 Re: pg_receivexlog --status-interval add fsync feedback
Previous Message Andrew Dunstan 2014-10-23 14:23:43 Re: idea: allow AS label inside ROW constructor