Re: ISN extension - wrong volatility level for isn_weak() function
Viktor Holmberg <v@viktorh.net>
From: Viktor Holmberg <v@viktorh.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Gustafsson <daniel@yesql.se>,
pgsql-bugs@lists.postgresql.org
Date: 2025-03-14T16:08:36Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
contrib/isn: Make weak mode a GUC setting, and fix related functions.
- 44890442398c 18.0 landed
-
Update contrib/seg for new scalarlesel/scalargesel selectivity functions.
- 44ba29206449 11.0 cited
Thanks, I did check that thread during my desperate attempts to figure this bug out. In terms of the ergonomics of is_valid I think it’s actually quite nice. A GUC variable would be very nice - I kinda assumed the ISN module was create before GUC, hence the somewhat idiosyncratic is_weak(bool) session level setting. However, cleaning things up to use GUC seems like it’d be bigger task, and also would only be an extra thing, as isn_weak function would need to stay in for backwards compatibility I assume. In terms of just fixing the immediate bug, I believe it’d just be to change isn.sql line 3423 and 2433: CREATE FUNCTION isn_weak() RETURNS boolean AS 'MODULE_PATHNAME', 'weak_input_status' LANGUAGE C IMMUTABLE STRICT <— should be VOLATILE STRICT PARALLEL RESTRICTED; I believe even I could do this change, unless one of you pros would be open to doing it. Am I right in understanding the next steps to do that would be to create a patch, and email it to pgsql-hackers? Or does that patch go here? Thanks /Viktor On 14 Mar 2025 at 15:14 +0000, Tom Lane <tgl@sss.pgh.pa.us>, wrote: > Viktor Holmberg <v@viktorh.net> writes: > > I haven’t checked the source code, but yes the isn_weak feature has some footgun potential. As it doesn’t respect transactions, but rather sets a flag on session level, it’s easy for the “isn weakness” to leak out into a connection pool. > > Yeah, really that ought to be a GUC I should think. There isn't > anything well-designed about it ... > > I found some prior discussion here: > > https://www.postgresql.org/message-id/flat/C12AE0A2A752416C79F3EE81%40teje > > but we don't seem to have pulled the trigger on changing anything. > > regards, tom lane