Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v4Pgi-00Eicy-2o for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Oct 2025 20:14:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v4Pge-0094BP-16 for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Oct 2025 20:14:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v4Pgd-0094BG-Ou for pgsql-bugs@lists.postgresql.org; Thu, 02 Oct 2025 20:14:00 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v4Pgb-0004lM-1s for pgsql-bugs@lists.postgresql.org; Thu, 02 Oct 2025 20:13:59 +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 592KDtIU1156184; Thu, 2 Oct 2025 16:13:55 -0400 From: Tom Lane To: m.walczak@megavision.pl cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19069: pg_advisory_xact_lock() in a WITH query doesn't work In-reply-to: <19069-f5c72e4e4f921a7c@postgresql.org> References: <19069-f5c72e4e4f921a7c@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Thu, 02 Oct 2025 13:11:37 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1156182.1759436035.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 02 Oct 2025 16:13:55 -0400 Message-ID: <1156183.1759436035@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form 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