Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1piDz9-0006wo-L6
	for pgsql-docs@arkaria.postgresql.org; Fri, 31 Mar 2023 12:36:03 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1piDz8-0002Uh-5a
	for pgsql-docs@arkaria.postgresql.org; Fri, 31 Mar 2023 12:36:02 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1piDz7-0002UX-UR
	for pgsql-docs@lists.postgresql.org; Fri, 31 Mar 2023 12:36:01 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1piDz5-0004JA-D9
	for pgsql-docs@lists.postgresql.org; Fri, 31 Mar 2023 12:36:01 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 32VCZtw1387587;
	Fri, 31 Mar 2023 08:35:55 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: zacharymschultz@gmail.com, pgsql-docs@lists.postgresql.org
Subject: Re: Minor typo in 13.3.5. Advisory Locks
In-reply-to: <76AEBCC7-5C7C-4A30-B3C3-8FAB1883C789@yesql.se>
References: <168001423502.628.12487124747594890228@wrigleys.postgresql.org>
 <3663048.1680036353@sss.pgh.pa.us>
 <76AEBCC7-5C7C-4A30-B3C3-8FAB1883C789@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Fri, 31 Mar 2023 10:25:24 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <387585.1680266155.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Mar 2023 08:35:55 -0400
Message-ID: <387586.1680266155@sss.pgh.pa.us>
List-Id: <pgsql-docs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-docs@lists.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-docs>
Archived-At: 
 <https://www.postgresql.org/message-id/387586.1680266155%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
> Reading this section I agree that the mix of ok/danger in the same examp=
le can
> be tad misleading though.  Something like the attached is what I would p=
refer
> as a reader.

I think in your rewrite, "this query" is dangling a bit because there's
several sentences more before the query actually appears.  I suggest
ordering things more like:

     expressions are evaluated.  For example,
     this query is dangerous because the
     <literal>LIMIT</literal> is not guaranteed to be applied before the l=
ocking
     function is executed:
<screen>
SELECT pg_advisory_lock(id) FROM foo WHERE id &gt; 12345 LIMIT 100; -- dan=
ger!
</screen>
     This might cause some locks to be acquired
     that the application was not expecting, and hence would fail to
     ...
     On the other hand, these queries are safe:
<screen>
SELECT pg_advisory_lock(id) FROM foo WHERE id =3D 12345; -- ok
...

Separately from that: now that I look at this example, it's really
quite safe for any plausible plan shape.  It used to be dangerous if
you had an ORDER BY, but there's no ORDER BY, and even if there were
we fixed that in 9118d03a8.  Do we want to choose another example, and
if so what?  The "not guaranteed" wording isn't really wrong, but an
example that doesn't do what we're saying it does isn't good either.

			regards, tom lane