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?= <kyzeva...@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
