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 1tt68O-008agP-NV for pgsql-bugs@arkaria.postgresql.org; Fri, 14 Mar 2025 14:35:36 +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 1tt68N-0098O0-Fs for pgsql-bugs@arkaria.postgresql.org; Fri, 14 Mar 2025 14:35:35 +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 1tt61x-008viO-Bm for pgsql-bugs@lists.postgresql.org; Fri, 14 Mar 2025 14:28:57 +0000 Received: from out-03.pe-bsn.jellyfish.systems ([66.29.159.81]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tt61t-002qiN-0M for pgsql-bugs@lists.postgresql.org; Fri, 14 Mar 2025 14:28:56 +0000 Received: from prod-lbout-phx.jellyfish.systems (bsn-02-6.privateemail.com [198.54.118.197]) by pe-bsn.jellyfish.systems (Postfix) with ESMTPA id 4ZDmvP2yFNz2ylt; Fri, 14 Mar 2025 14:28:49 +0000 (UTC) Received: from MTA-14.privateemail.com (unknown [10.50.14.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by BSN-02.privateemail.com (Postfix) with ESMTPS id 4ZDmvP2Rz6z3hhTh; Fri, 14 Mar 2025 10:28:49 -0400 (EDT) Received: from mta-14.privateemail.com (localhost [127.0.0.1]) by mta-14.privateemail.com (Postfix) with ESMTP id 4ZDmvP1DQQz3hhTk; Fri, 14 Mar 2025 10:28:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=viktorh.net; s=default; t=1741962529; bh=c9pK4n4YZoQF8GAEb3Rmk4P72EcFMAQdjnBkKA8mSks=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=TP+7suKQzrO/rNOUVoR40XsbLljpfksX9x50Vfo+sARd5qocm8CJ6oaPEs+OBSBj/ nyhe/fMk4xbdVWobYu7d5oZ41s8XFb5xDAgGGKP9i3UWWjXOFqRgY5knZzsXF2Szju tVF9B9bTtUy7woREXfSGhGZeklS9KRVm91O3fABszlzUOoW2PL1OtM2FoMZOGDrWUz mGVan01t0Xh9UuUzeU/jiVfcoVwT0JyXJxssLBc9GFYXS+pa6r70eK8/10jyCy2mSm vI8EH70qVPfIL8c3aNFfoI+aZw9aWpA4BFMCNS4qoGtyVVdau/JTl9QoDUfJwT2/lq f6fXjdspUiYcg== Received: from [10.34.123.152] (unknown [80.87.18.224]) by mta-14.privateemail.com (Postfix) with ESMTPA; Fri, 14 Mar 2025 10:28:46 -0400 (EDT) Date: Fri, 14 Mar 2025 14:28:01 +0000 From: Viktor Holmberg To: Daniel Gustafsson , Tom Lane Cc: pgsql-bugs@lists.postgresql.org Message-ID: In-Reply-To: <3052531.1741961784@sss.pgh.pa.us> References: <790bc1f9-74dc-4b50-94d2-8147315b1556@Spark> <51C655A4-46FB-4A40-BAE5-26A76B31D3EE@yesql.se> <3052531.1741961784@sss.pgh.pa.us> Subject: Re: ISN extension - wrong volatility level for isn_weak() function X-Readdle-Message-ID: de89bd5c-9f51-4891-8a38-d03ed06ebd1d@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="67d43d01_2a487cb0_1881" X-Virus-Scanned: ClamAV using ClamSMTP List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --67d43d01_2a487cb0_1881 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I haven=E2=80=99t checked the source code, but yes the isn=5Fweak feature= has some footgun potential. As it doesn=E2=80=99t respect transactions, = but rather sets a flag on session level, it=E2=80=99s easy for the =E2=80= =9Cisn weakness=E2=80=9D to leak out into a connection pool. Still the feature is very useful as I work with many suppliers who give u= s product lists full of invalid EANs, which still need to be ingested. /Viktor On 14 Mar 2025 at 14:16 +0000, Tom Lane , wrote: > Daniel Gustafsson writes: > > On 14 Mar 2025, at 12:49, Viktor Holmberg wrote: > > > The isn=5Fweak function in the isn extension reports the wrong valu= e if you look at it inside a transaction: > > > I wonder if this should really be marked VOLATILE instead as it has a= side > > effect. > > Indeed. This whole area seems really poorly considered. The comment > in isn--1.1.sql says > > -- isn=5Fweak(boolean) - Sets the weak input mode. > -- This function is intended for testing use only=21 > > despite which it's documented at length in isn.sgml. On the other > hand, so far as I can find it's tested nowhere, which means none > of the =22weak mode=22 code is getting exercised. > > regards, tom lane --67d43d01_2a487cb0_1881 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I haven=E2= =80=99t checked the source code, but yes the isn=5Fweak feature has some = footgun potential. As it doesn=E2=80=99t respect transactions, but rather= sets a flag on session level, it=E2=80=99s easy for the =E2=80=9Cisn wea= kness=E2=80=9D to leak out into a connection pool.&=23160;
Still the feature is very usefu= l as I work with many suppliers who give us product lists full of invalid= EANs, which still need to be ingested.

/Viktor
On 14 Mar 2025 at 14:16 +0000, Tom = Lane <tgl=40sss.pgh.pa.us>, wrote:
Daniel Gustafsson <daniel=40yesql.se> writes:
On 14 Mar 2025, at 12:49, Viktor Holmberg &= lt;v=40viktorh.net> wrote:
The isn=5Fweak function in the isn extensio= n reports the wrong value if you look at it inside a transaction:

I wonder if this should really be marked VO= LATILE instead as it has a side
effect.

Indeed. This whole area seems really poorly considered. The comment
= in isn--1.1.sql says

-- isn=5Fweak(boolean) - Sets the weak input mode.
-- This function is intended for testing use only=21

despite which it's documented at length in isn.sgml. On the other
hand, so far as I can find it's tested nowhere, which means none
of the =22weak mode=22 code is getting exercised.

regards, tom lane
--67d43d01_2a487cb0_1881--