Subject: Re: Latest patches break one of our unit-test, related to RLS

From: Dominique Devienne <[email-masked]>
Date: Fri, 12 Sep 2025 14:22:54 +0200

On Thu, Sep 4, 2025 at 5:03 PM Dominique Devienne <[email-masked]> wrote:
> OK with 16.9 and 17.5 (we cannot test on beta2 anymore)
> KO with 16.10 and 17.6 (and beta3 too, released at the same time)

I've tracked down the regression to this particular query, FWIW:

select rolname, rolsuper, rolinherit, rolcreaterole,
       rolcreatedb, rolcanlogin, rolreplication, rolbypassrls,
       oid, shobj_description(oid, 'pg_authid')
  from pg_roles
 where rolname SIMILAR TO $1 AND pg_has_role(oid, 'SET')
 order by rolname

In 17.5, returns 3 rows.
In 17.6, returns 0 rows.

I've used a libpq trace on both, diff'd them, and it's the 1st
significant difference.

Given my troubles with roles, I immediately imagined a change in pg_has_role().
But turns out, it's SIMILAR TO that changed. See trace extract below
for both versions.

On 17.6

On the two queries below, the first is the real one,
(modulo some mild renaming, to Acme and FOO)
and the second is one where I replaced the [\d\w] with a _
The correct answer for the 1st should be (7 rows).
This particular char I test on, can be / and :
but I want to avoid those entries, thus [\d\w]

So, it this a regression? A bug fix, and my pattern is somehow wrong?
If it's not a bug/regression, what do you suggest we use instead?

If it is a bug, any chance it might be in the upcoming v18 release
(and associated earlier version patches???)

I think I've found the smoking gun. Haven't verified whether our
troubles with v18 pre-releases is related.

Thanks, --DD

PS: From those 7 rows, pg_has_role() is supposed to narrow it down to 3.

acme=> select rolname from pg_roles where rolname similar to
'Acme-FOO:8n8igcOH[\d\w]_____________:%' order by 1;
 rolname
---------
(0 rows)

acme=> select rolname from pg_roles where rolname similar to
'Acme-FOO:8n8igcOH______________:%' order by 1;
                  rolname
-------------------------------------------
...
(14 rows)

And the same as above, on 17.5:

acme=> select rolname from pg_roles where rolname similar to
'Acme-FOO:8vjqDaeT[\d\w]_____________:%' order by 1;
                rolname
----------------------------------------
...
(7 rows)

acme=> select rolname from pg_roles where rolname similar to
'Acme-FOO:8vjqDaeT______________:%' order by 1;
                  rolname
-------------------------------------------
...
(14 rows)

--------------- llibpq traces -------------------
17.5

2025-09-12 13:50:32.267733 B 5 ReadyForQuery I
2025-09-12 13:50:32.267772 F 270 Parse "" "

select rolname, rolsuper, rolinherit, rolcreaterole,
       rolcreatedb, rolcanlogin, rolreplication, rolbypassrls,
       oid, shobj_description(oid, 'pg_authid')
  from pg_roles
 where rolname SIMILAR TO $1 AND pg_has_role(oid, 'SET')
 order by rolname

" 1 25
2025-09-12 13:50:32.267775 F 58 Bind "" "" 1 1 1 38
'Acme-FOO:8vjqDaeT[\d\w]_____________:%' 1 1
2025-09-12 13:50:32.267777 F 6 Describe P ""
2025-09-12 13:50:32.267779 F 9 Execute "" 0
2025-09-12 13:50:32.267780 F 4 Sync
2025-09-12 13:50:32.271148 B 4 ParseComplete
2025-09-12 13:50:32.271161 B 4 BindComplete
2025-09-12 13:50:32.271165 B 302 RowDescription 10 "rolname" 12000 1
19 64 -1 1 "rolsuper" 12000 2 16 1 -1 1 "rolinherit" 12000 3 16 1 -1 1
"rolcreaterole" 12000 4 16 1 -1 1 "rolcreatedb" 12000 5 16 1 -1 1
"rolcanlogin" 12000 6 16 1 -1 1 "rolreplication" 12000 7 16 1 -1 1
"rolbypassrls" 12000 11 16 1 -1 1 "oid" 12000 13 26 4 -1 1
"shobj_description" 0 0 25 65535 -1 1
...
2025-09-12 13:50:32.271200 B 13 CommandComplete "SELECT 3"

in 17.6

2025-09-12 13:50:52.512043 B 5 ReadyForQuery I
2025-09-12 13:50:52.512082 F 270 Parse "" "

select rolname, rolsuper, rolinherit, rolcreaterole,
       rolcreatedb, rolcanlogin, rolreplication, rolbypassrls,
       oid, shobj_description(oid, 'pg_authid')
  from pg_roles
 where rolname SIMILAR TO $1 AND pg_has_role(oid, 'SET')
 order by rolname

" 1 25
2025-09-12 13:50:52.512085 F 58 Bind "" "" 1 1 1 38
'Acme-FOO:8n8igcOH[\d\w]_____________:%' 1 1
2025-09-12 13:50:52.512088 F 6 Describe P ""
2025-09-12 13:50:52.512089 F 9 Execute "" 0
2025-09-12 13:50:52.512091 F 4 Sync
2025-09-12 13:50:52.540088 B 4 ParseComplete
2025-09-12 13:50:52.540104 B 4 BindComplete
2025-09-12 13:50:52.540109 B 302 RowDescription 10 "rolname" 12000 1
19 64 -1 1 "rolsuper" 12000 2 16 1 -1 1 "rolinherit" 12000 3 16 1 -1 1
"rolcreaterole" 12000 4 16 1 -1 1 "rolcreatedb" 12000 5 16 1 -1 1
"rolcanlogin" 12000 6 16 1 -1 1 "rolreplication" 12000 7 16 1 -1 1
"rolbypassrls" 12000 11 16 1 -1 1 "oid" 12000 13 26 4 -1 1
"shobj_description" 0 0 25 65535 -1 1
2025-09-12 13:50:52.540119 B 13 CommandComplete "SELECT 0"

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 12 Sep 2025 14:45:56 +0200

>  where rolname SIMILAR TO $1 AND pg_has_role(oid, 'SET')

That must be commit e3ffc3e91d.

That commit fixed a bug in the conversion from SIMILAR TO
expressions to POSIX regular expressions.

You don't show us that data that match the pattern in 17.5, but
not in 17.6.  Unless you show us a counterexample, I'd say that
the behavior in 17.6 is correct.

Minor releases shouldn't change the behavior EXCEPT when the
behavior is buggy.

Yours,
Laurenz Albe

---

From: Dominique Devienne <[email-masked]>
Date: Fri, 12 Sep 2025 15:11:10 +0200

> Minor releases shouldn't change the behavior EXCEPT when the

Can't get any simpler than the repro below, can it?
So is this buggy or not?
Clearly, there's a change in behavior.
I tend to call a change in behavior as a regression myself :)
But if someone can explain to me how what used to work was incorrect,
compared to the documented behavior,
I'm willing to change it of course. Any takers? --DD

postgres=# show server_version;
 server_version
----------------
 16.9
(1 row)

postgres=# with t(v) as (values ('foo:bar'), ('foo/bar'), ('foo0bar'))
select v from t where v similar to 'foo[\d\w]_%';
    v
---------
 foo0bar
(1 row)

postgres=# \c - - - 5416;
psql (17.6, server 16.10)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384,
compression: off, ALPN: none)
You are now connected to database "postgres" as user "postgres" on
host "sr-pau-db" (address "10.65.53.13") at port "5416".
postgres=# show server_version;
 server_version
----------------
 16.10
(1 row)

postgres=# with t(v) as (values ('foo:bar'), ('foo/bar'), ('foo0bar'))
select v from t where v similar to 'foo[\d\w]_%';
 v
---
(0 rows)

postgres=# \c - - - 5475
psql (17.6, server 17.5)
You are now connected to database "postgres" as user "postgres" on
host "sr-pau-db" (address "10.65.53.13") at port "5475".
postgres=# show server_version;
 server_version
----------------
 17.5
(1 row)

postgres=# with t(v) as (values ('foo:bar'), ('foo/bar'), ('foo0bar'))
select v from t where v similar to 'foo[\d\w]_%';
    v
---------
 foo0bar
(1 row)

postgres=# \c - - - 5417
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384,
compression: off, ALPN: postgresql)
You are now connected to database "postgres" as user "postgres" on
host "sr-pau-db" (address "10.65.53.13") at port "5417".
postgres=# show server_version;
 server_version
----------------
 17.6
(1 row)

postgres=# with t(v) as (values ('foo:bar'), ('foo/bar'), ('foo0bar'))
select v from t where v similar to 'foo[\d\w]_%';
 v
---
(0 rows)

postgres=# \c - - - 5481
psql (17.6, server 18rc1)
WARNING: psql major version 17, server major version 18.
         Some psql features might not work.
You are now connected to database "postgres" as user "postgres" on
host "sr-pau-db" (address "10.65.53.13") at port "5481".
postgres=# show server_version;
 server_version
----------------
 18rc1
(1 row)

postgres=# with t(v) as (values ('foo:bar'), ('foo/bar'), ('foo0bar'))
select v from t where v similar to 'foo[\d\w]_%';
 v
---
(0 rows)

postgres=#