Horton

Re: DROP OWNED BY fails to clean out pg_init_privs grants

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Егор Чиндяскин <kyzevan23@mail.ru>
Cc: Robert Haas <robertmhaas@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, David G. Johnston <david.g.johnston@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, Noah Misch <nmisch@google.com>, Hannu Krosing <hannuk@google.com>
Date: 2024-09-18T04:31:27Z
Lists: pgsql-hackers 
=?UTF-8?B?0JXQs9C+0YAg0KfQuNC90LTRj9GB0LrQuNC9?= <kyzevan23@mail.ru> writes:
> This query does not expect that test database may already contain some information about custom user that ran test_pg_dump-running.

I'm perfectly content to reject this as being an abuse of the test
case.  Our TAP tests are built on the assumption that they use
databases created within the test case.  Apparently, you've found a
way to use the meson test infrastructure to execute a TAP test in
the equivalent of "make installcheck" rather than "make check" mode.
I am unwilling to buy into the proposition that our TAP tests should
be proof against doing that after making arbitrary changes to the
database's initial state.  If anything, the fact that this is possible
is a bug in our meson scripts.

			regards, tom lane

Commits

  1. Allow meson builds to run test_pg_dump test in installcheck mode.

  2. Remove recordExtensionInitPriv[Worker]'s ownerId argument.

  3. Improve tracking of role dependencies of pg_init_privs entries.

  4. Fix failure to track role dependencies of pg_init_privs entries.

  5. Drop global objects after completed test