public inbox for [email protected]
help / color / mirror / Atom feedAdd further details to ROW SHARE table level lock modes section
3+ messages / 3 participants
[nested] [flat]
* Add further details to ROW SHARE table level lock modes section
@ 2022-04-04 15:54 PG Doc comments form <[email protected]>
2022-04-13 18:00 ` Re: Add further details to ROW SHARE table level lock modes section Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: PG Doc comments form @ 2022-04-04 15:54 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/explicit-locking.html
Description:
The ROW SHARE table level lock modes section currently states:
```
Conflicts with the EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
The SELECT FOR UPDATE and SELECT FOR SHARE commands acquire a lock of this
mode on the target table(s) (in addition to ACCESS SHARE locks on any other
tables that are referenced but not selected FOR UPDATE/FOR SHARE).
```
I propose that it would be useful to explicitly state that `SELECT FOR KEY
SHARE` AND `SELECT FOR NO KEY UPDATE` commands also acquire the ROW SHARE
table level lock on target table(s). That is:
```
Conflicts with the EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
The SELECT FOR UPDATE, SELECT FOR NO KEY UPDATE, SELECT FOR SHARE, and
SELECT FOR KEY SHARE commands acquire a lock of this mode on the target
table(s) (in addition to ACCESS SHARE locks on any other tables that are
referenced but not selected FOR UPDATE/FOR SHARE).
```
Thank you for your time.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Add further details to ROW SHARE table level lock modes section
2022-04-04 15:54 Add further details to ROW SHARE table level lock modes section PG Doc comments form <[email protected]>
@ 2022-04-13 18:00 ` Alvaro Herrera <[email protected]>
2022-04-13 18:11 ` Re: Add further details to ROW SHARE table level lock modes section Erikjan Rijkers <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Alvaro Herrera @ 2022-04-13 18:00 UTC (permalink / raw)
To: [email protected]; [email protected]
On 2022-Apr-04, PG Doc comments form wrote:
> I propose that it would be useful to explicitly state that `SELECT FOR KEY
> SHARE` AND `SELECT FOR NO KEY UPDATE` commands also acquire the ROW SHARE
> table level lock on target table(s). That is:
> ```
> Conflicts with the EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
>
> The SELECT FOR UPDATE, SELECT FOR NO KEY UPDATE, SELECT FOR SHARE, and
> SELECT FOR KEY SHARE commands acquire a lock of this mode on the target
> table(s) (in addition to ACCESS SHARE locks on any other tables that are
> referenced but not selected FOR UPDATE/FOR SHARE).
> ```
I agree we need an update here. But the original wording seems a bit
off; I think we should say SELECT is a command, and that the FOR bits
are options thereof. Maybe something like this:
<para>
The <command>SELECT</command> command acquires a lock of this mode
on all tables on which one of the <option>FOR UPDATE</option>,
<option>FOR NO KEY UPDATE</option>,
<option>FOR SHARE</option>, or
<option>FOR KEY SHARE</option> options is specified
(in addition to <literal>ACCESS SHARE</literal> locks on any other
tables that are referenced without any explicit
<option>FOR ...</option> locking option).
</para>
Thoughts?
Grammar check: "one of the a,b,c options IS specified" or "one of the
a,b,c options ARE specified"?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Add further details to ROW SHARE table level lock modes section
2022-04-04 15:54 Add further details to ROW SHARE table level lock modes section PG Doc comments form <[email protected]>
2022-04-13 18:00 ` Re: Add further details to ROW SHARE table level lock modes section Alvaro Herrera <[email protected]>
@ 2022-04-13 18:11 ` Erikjan Rijkers <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Erikjan Rijkers @ 2022-04-13 18:11 UTC (permalink / raw)
To: [email protected]
Op 13-04-2022 om 20:00 schreef Alvaro Herrera:
> On 2022-Apr-04, PG Doc comments form wrote:
>
>> I propose that it would be useful to explicitly state that `SELECT FOR KEY
>> SHARE` AND `SELECT FOR NO KEY UPDATE` commands also acquire the ROW SHARE
>> table level lock on target table(s). That is:
>> ```
>> Conflicts with the EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
>>
>> The SELECT FOR UPDATE, SELECT FOR NO KEY UPDATE, SELECT FOR SHARE, and
>> SELECT FOR KEY SHARE commands acquire a lock of this mode on the target
>> table(s) (in addition to ACCESS SHARE locks on any other tables that are
>> referenced but not selected FOR UPDATE/FOR SHARE).
>> ```
>
> I agree we need an update here. But the original wording seems a bit
> off; I think we should say SELECT is a command, and that the FOR bits
> are options thereof. Maybe something like this:
>
> <para>
> The <command>SELECT</command> command acquires a lock of this mode
> on all tables on which one of the <option>FOR UPDATE</option>,
> <option>FOR NO KEY UPDATE</option>,
> <option>FOR SHARE</option>, or
> <option>FOR KEY SHARE</option> options is specified
> (in addition to <literal>ACCESS SHARE</literal> locks on any other
> tables that are referenced without any explicit
> <option>FOR ...</option> locking option).
> </para>
>
> Thoughts?
>
> Grammar check: "one of the a,b,c options IS specified" or "one of the
> a,b,c options ARE specified"?
one [...] IS specified
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-04-13 18:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-04-04 15:54 Add further details to ROW SHARE table level lock modes section PG Doc comments form <[email protected]>
2022-04-13 18:00 ` Alvaro Herrera <[email protected]>
2022-04-13 18:11 ` Erikjan Rijkers <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox