Re: tests fail on windows with default git settings - Mailing list pgsql-hackers
From | Dave Page |
---|---|
Subject | Re: tests fail on windows with default git settings |
Date | |
Msg-id | CA+OCxownCBPWUUpvMRz=CWPyzeqV3no1Z-YBuWMVMtk9V2u4fQ@mail.gmail.com Whole thread Raw |
In response to | Re: tests fail on windows with default git settings (Andres Freund <andres@anarazel.de>) |
Responses |
Re: tests fail on windows with default git settings
|
List | pgsql-hackers |
On Tue, 9 Jul 2024 at 17:32, Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2024-07-09 14:52:39 +0100, Dave Page wrote:
> I have 4 different diff.exe's on my ~6 week old build VM (not counting
> shims), all of which seem to support --strip-trailing-cr. Those builds came
> with:
>
> - git
> - VC++
> - diffutils (installed by chocolatey)
> - vcpkg
>
> I think it's reasonable to assume it'll be supported.
I think the more likely issue would be an older setup with an older diff,
people on windows seem to not want to touch a working setup ever :). But we
can deal with that if reports about it come in.
They've got to move to meson/ninja anyway, so... <shrug>.
> > > Not sure what the issue is with pg_bsd_indent, though.
> >
>
> Yeah - that's odd, as that test always passes for me, with or without
> autocrlf.
Huh.
> 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 auth related errors as well. For example, this is from
FWIW, building a tree with the patches I sent to the list last night and
changes to make postgresql-dev.yml use a git checkout, I get:
https://github.com/anarazel/winpgbuild/actions/runs/9852370209/job/27200784987#step:12:469
Ok: 281
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 17
Timeout: 0
This is without readline and pltcl, as neither is currently built as part of
winpgbuild. Otherwise it has all applicable dependencies enabled (no bonjour,
bsd_auth, dtrace, llvm, pam, selinux, systemd, but that's afaict expected).
Greetings,
Andres Freund
[1] I plan to submit a PR that'll collect the necessary information
Dave Page
pgAdmin: https://www.pgadmin.org
pgsql-hackers by date: