Re: pgsql: Catalog changes preparing for builtin collation provider.

On Sat, 2024-03-09 at 22:50 +0000, Jeff Davis wrote:
> Catalog changes preparing for builtin collation provider.

This is causing problems on a couple buildfarm members (mantid,
lapwing, snakefly) that all look like this:

# Running: pg_upgrade --no-sync -d
/home/postgres/buildroot/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/
t_002_pg_upgrade_old_node_data/pgdata -D
/home/postgres/buildroot/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/
t_002_pg_upgrade_new_node_data/pgdata -b
/home/postgres/buildroot/HEAD/pgsql.build/tmp_install/home/postgres/bui
ldroot/HEAD/inst/bin -B
/home/postgres/buildroot/HEAD/pgsql.build/tmp_install/home/postgres/bui
ldroot/HEAD/inst/bin -s /tmp/3b07YyaACZ -p 52828 -P 52829 --copy --
check
[01:08:08.992](1.053s) ok 9 - invalid database causes failure status
(got 1 vs expected 1)
[01:08:08.992](0.001s) ok 10 - invalid database causes failure stdout
/(?^:invalid)/
[01:08:08.993](0.001s) not ok 11 - invalid database causes failure
stderr /(?^:)/
[01:08:08.993](0.000s)
[01:08:08.993](0.000s) #   Failed test 'invalid database causes failure
stderr /(?^:)/'
[01:08:08.993](0.000s) #   at t/002_pg_upgrade.pl line 370.
[01:08:08.994](0.000s) #                   ''
#     doesn't match '(?^:)'


That's a little confusing to me: the '(?^:)' is just qr//, which should
match anything, right?

It's expecting stderr to be empty, and the test failure seems to
indicate it is empty, so again I don't really see the problem.

Am I missing something obvious here?

Quite a few other members are passing and I didn't find an obvious
pattern yet.

Regards,
    Jeff Davis