Hello!
IIUC the regression test test_pg_dump [1] fails, see the attached
regression.diffs:
diff -U3
/Users/test/Work/postgrespro/src/test/modules/test_pg_dump/expected/test_pg_dump.out
/Users/test/Work/postgrespro/build/testrun/test_pg_dump-running/regress/results/test_pg_dump.out
---
/Users/test/Work/postgrespro/src/test/modules/test_pg_dump/expected/test_pg_dump.out 2024-09-12
15:02:26.345434331 +0700
+++
/Users/test/Work/postgrespro/build/testrun/test_pg_dump-running/regress/results/test_pg_dump.out 2024-09-12
15:42:09.341520173 +0700
[1]
https://github.com/postgres/postgres/blob/master/src/test/modules/test_pg_dump/sql/test_pg_dump.sql
On 2024-09-18 07:31, Tom Lane wrote:
> =?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
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
