Re: Minor typo in 13.3.5. Advisory Locks

> On 31 Mar 2023, at 14:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> Reading this section I agree that the mix of ok/danger in the same example can
>> be tad misleading though. Something like the attached is what I would prefer
>> 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 locking
> function is executed:
> <screen>
> SELECT pg_advisory_lock(id) FROM foo WHERE id &gt; 12345 LIMIT 100; -- danger!
> </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 = 12345; -- ok
> ...

Yes, I like this version a lot better than what I proposed.

> 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.

Off the cuff I don't have any better suggestions, need to do some more
thinking.

--
Daniel Gustafsson