On Wed, 10 Jul 2024 at 10:35, Dave Page <dp...@pgadmin.org> wrote: > > The other failures I see are the following, which I'm just starting to >>> dig >>> > into: >>> > >>> > 26/298 postgresql:recovery / recovery/019_replslot_limit >>> > ERROR 43.05s exit status 2 >>> > 44/298 postgresql:recovery / recovery/027_stream_regress >>> > ERROR 383.08s exit status 1 >>> > 50/298 postgresql:recovery / recovery/035_standby_logical_decoding >>> > ERROR 138.06s exit status 25 >>> > 68/298 postgresql:recovery / recovery/040_standby_failover_slots_sync >>> > ERROR 132.87s exit status 25 >>> > 170/298 postgresql:pg_dump / pg_dump/002_pg_dump >>> > ERROR 93.45s exit status 2 >>> > 233/298 postgresql:bloom / bloom/001_wal >>> > ERROR 54.47s exit status 2 >>> > 236/298 postgresql:subscription / subscription/001_rep_changes >>> > ERROR 46.46s exit status 2 >>> > 246/298 postgresql:subscription / subscription/010_truncate >>> > ERROR 47.69s exit status 2 >>> > 253/298 postgresql:subscription / subscription/013_partition >>> > ERROR 125.63s exit status 25 >>> > 255/298 postgresql:subscription / subscription/022_twophase_cascade >>> > ERROR 58.13s exit status 2 >>> > 257/298 postgresql:subscription / subscription/015_stream >>> > ERROR 128.32s exit status 2 >>> > 262/298 postgresql:subscription / subscription/028_row_filter >>> > ERROR 43.14s exit status 2 >>> > 263/298 postgresql:subscription / subscription/027_nosuperuser >>> > ERROR 102.02s exit status 2 >>> > 269/298 postgresql:subscription / subscription/031_column_list >>> > ERROR 123.16s exit status 2 >>> > 271/298 postgresql:subscription / subscription/032_subscribe_use_index >>> > ERROR 139.33s exit status 2 >>> >>> Hm, it'd be good to see some of errors behind that ([1]). >>> >>> I suspect it might be related to conflicting ports. I had to use >>> PG_TEST_USE_UNIX_SOCKETS to avoid random tests from failing: >>> >>> # use unix socket to prevent port conflicts >>> $env:PG_TEST_USE_UNIX_SOCKETS = 1; >>> # otherwise pg_regress insists on creating the directory and >>> does it >>> # in a non-existing place, this needs to be fixed :( >>> mkdir d:/sockets >>> $env:PG_REGRESS_SOCK_DIR = "d:/sockets/" >>> >> >> No, it all seems to be fallout from GSSAPI being included in the build. >> If I build without that, everything passes. Most of the tests are failing >> with a "too many clients already" error, but a handful do seem to include >> GSSAPI auth related errors as well. For example, this is from >> > > > ... this is from subscription/001_rep_changes: > > [14:46:57.723](2.318s) ok 11 - check rows on subscriber after table drop > from publication > connection error: 'psql: error: connection to server at "127.0.0.1", port > 58059 failed: could not initiate GSSAPI security context: No credentials > were supplied, or the credentials were unavailable or inaccessible: > Credential cache is empty > connection to server at "127.0.0.1", port 58059 failed: FATAL: sorry, too > many clients already' > while running 'psql -XAtq -d port=58059 host=127.0.0.1 dbname='postgres' > -f - -v ON_ERROR_STOP=1' at > C:/Users/dpage/git/postgresql/src/test/perl/PostgreSQL/Test/Cluster.pm line > 2129. > # Postmaster PID for node "publisher" is 14488 > ### Stopping node "publisher" using mode immediate > # Running: pg_ctl -D > C:\Users\dpage\git\postgresql\build/testrun/subscription/001_rep_changes\data/t_001_rep_changes_publisher_data/pgdata > -m immediate stop > waiting for server to shut down.... done > server stopped > # No postmaster PID for node "publisher" > # Postmaster PID for node "subscriber" is 15012 > ### Stopping node "subscriber" using mode immediate > # Running: pg_ctl -D > C:\Users\dpage\git\postgresql\build/testrun/subscription/001_rep_changes\data/t_001_rep_changes_subscriber_data/pgdata > -m immediate stop > waiting for server to shut down.... done > server stopped > # No postmaster PID for node "subscriber" > [14:46:59.068](1.346s) # Tests were run but no plan was declared and > done_testing() was not seen. > [14:46:59.069](0.000s) # Looks like your test exited with 2 just after 11. >
So I received an off-list tip to checkout [1], a discussion around GSSAPI causing test failures on windows that Alexander Lakhin was looking at. Thomas Munro's v2 patch to try to address the issue brought me down to just a single test failure with GSSAPI enabled on 17b2 (with a second, simple fix for the OpenSSL/Kerberos/x509 issue): pg_dump/002_pg_dump. The relevant section from the log looks like this: [15:28:42.692](0.006s) not ok 2 - connecting to a non-existent database: matches [15:28:42.693](0.001s) # Failed test 'connecting to a non-existent database: matches' # at C:/Users/dpage/git/postgresql/src/bin/pg_dump/t/002_pg_dump.pl line 4689. [15:28:42.694](0.001s) # 'pg_dump: error: connection to server at "127.0.0.1", port 53834 failed: could not initiate GSSAPI security context: No credentials were supplied, or the credentials were unavailable or inaccessible: Credential cache is empty # connection to server at "127.0.0.1", port 53834 failed: FATAL: database "qqq" does not exist # ' # doesn't match '(?^:pg_dump: error: connection to server .* failed: FATAL: database "qqq" does not exist)' # Running: pg_dump -d regression_invalid We could tweak the regex I suppose, but that just seems like it's skirting around the actual problem. I could also get on board with Tom's idea of deprecating GSSAPI for Windows, assuming that SSPI can handle everything users might reasonably need (I really have no idea how likely that is). [1] ttps://www.postgresql.org/message-id/847814.1715631...@sss.pgh.pa.us <https://www.postgresql.org/message-id/847814.1715631...@sss.pgh.pa.us> -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com
