From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Noah Misch <noah(at)leadboat(dot)com> |
Subject: | Too-long socket paths are breaking several buildfarm members |
Date: | 2022-07-03 23:22:11 |
Message-ID: | 1410025.1656890531@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Buildfarm member thorntail has yet to pass the pg_upgrade test
in the REL_15_STABLE branch. It looks like the problem reduces to
an overlength pathname:
2022-07-04 00:27:03.404 MSK [2212393:2] LOG: Unix-domain socket path "/home/nm/farm/sparc64_deb10_gcc_64_ubsan/REL_15_STABLE/pgsql.build/src/bin/pg_upgrade/tmp_check/.s.PGSQL.49714" is too long (maximum 107 bytes)
That path name is 3 bytes over the platform limit. Evidently,
"REL_15_STABLE" is just enough longer than "HEAD" to make this fail,
whereas we didn't see the problem as long as the test case only
ran in HEAD.
Members butterflyfish, massasauga, and myna likewise have yet to pass
this test in REL_15_STABLE, though they're perfectly happy in HEAD.
They are returning cut-down logs that don't allow diagnosing for
certain, but a reasonable bet is that it's the same kind of problem.
I think that the conversion of pg_upgrade's test script to TAP
form missed a bet. IIRC, we have mechanism somewhere to ensure
that test socket path names are created under /tmp, or someplace else
that's not subject to possibly-long paths of installation directories.
That's evidently not being used here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-04 00:08:19 | Re: AIX support - alignment issues |
Previous Message | Thomas Munro | 2022-07-03 22:33:37 | Re: AIX support - alignment issues |