PG Bug reporting form <noreply@postgresql.org> writes:
> This doesn't actually do any locking:
> BEGIN;
> WITH my_lock AS (
> SELECT pg_advisory_xact_lock(1)
> )
> INSERT INTO my_table (...) VALUES (...);
> COMMIT;
That looks as-expected to me. The docs say [1]
[ This works because ] PostgreSQL's implementation evaluates only
as many rows of a WITH query as are actually fetched by the parent
query.
which is to say, none at all in this case. There's also this in [2]:
Data-modifying statements in WITH are executed exactly once, and
always to completion, independently of whether the primary query
reads all (or indeed any) of their output. Notice that this is
different from the rule for SELECT in WITH: as stated in the
previous section, execution of a SELECT is carried only as far as
the primary query demands its output.
You're apparently expecting the presence of a volatile function
to cause the SELECT to be reclassified as data-modifying, but
we don't do it that way.
I'd recommend being less cute and just writing
BEGIN;
SELECT pg_advisory_xact_lock(1);
INSERT INTO my_table (...) VALUES (...);
COMMIT;
regards, tom lane
[1] https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-CYCLE
[2] https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-MODIFYING
