Re: SQL Property Graph Queries (SQL/PGQ)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, assam258(at)gmail(dot)com, Amit Langote <amitlangote09(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Ajay Pal <ajay(dot)pal(dot)k(at)gmail(dot)com>, Imran Zaheer <imran(dot)zhir(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Date: 2026-03-18 21:15:57
Message-ID: 1064400.1773868557@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> On Wed, Mar 18, 2026 at 12:59 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> There are still some pg_upgrade-related failures on the buildfarm, but
>> AFAICT these are not specifically from this feature but more from the
>> test design of the PG_TEST_EXTRA="regress_dump_restore" test. It looks
>> like we need to drop all users at the end of
>> src/test/regress/sql/graph_table_rls.sql to make this work.

> PFA the patch. I tried using --no-owner with pg_restore and pg_dump
> but that doesn't work since it doesn't exclude policies.

I just came across a side effect of this same thing. After running
"make installcheck", there are roles left behind:

regression=# \du
List of roles
Role name | Attributes
-------------------------------+------------------------------------------------------------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS
regress_graph_rls_alice | Cannot login
regress_graph_rls_bob | Cannot login
regress_graph_rls_carol | Cannot login
regress_graph_rls_dave | Cannot login
regress_graph_rls_exempt_user | Cannot login, Bypass RLS
regress_graph_rls_group1 | Cannot login
regress_graph_rls_group2 | Cannot login

I don't think this is acceptable at all. The contract for
installcheck testing, IMO, is that it doesn't leave behind any
permanent global effects other than the existence of the regression
database. Roles with elevated privileges seem like a particularly
dangerous thing to leave behind.

So I think we *must* drop all these roles at the end of the test,
regardless of the fact that not doing so breaks regress_dump_restore.
If you want to test dump/restore behavior with some non-default roles,
you have to do it in a TAP test that is using a purely temporary
installation. (But I hope we have adequate coverage for that
already.)

Your patch looks like it does that, but the test script's setup
could also be simplified, since it no longer has to contend with
the possibility that those roles are already there.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-03-18 21:17:40 Re: table AM option passing
Previous Message Corey Huinker 2026-03-18 21:00:34 Re: Return pg_control from pg_backup_stop().