On 9/18/23 20:52, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> it seems dikkop is unhappy again, this time because of some OpenSSL
>> stuff. I'm not sure it's our problem - it might be issues with the other
>> packages, or maybe something FreeBSD specific, not sure.
>> ...
>> Both 11 and 12 failed with a weird openssl segfaults in plpython tests,
>> see [2] and [3]. And 13 is stuck in some openssl stuff in plpython
>> tests, with 100% CPU usage (for ~30h now):
>
> Even weirder, its latest REL_11 run got past that, and instead failed
> in pltcl [1]. I suppose in an hour or two we'll know if v12 also
> changed behavior.
>
Oh, yeah. Sorry for not mentioning this yesterday ...
I tried removing the openssl-1.1.1v and installed 3.1 instead, which
apparently allowed it to pass the plpython tests. I guess it's due to
some sort of confusion with the openssl-3.0 included in FreeBSD base
(which I didn't realize is there).
> The pltcl test case that is failing is annotated
>
> -- Test usage of Tcl's "clock" command. In recent Tcl versions this
> -- command fails without working "unknown" support, so it's a good canary
> -- for initialization problems.
>
> which is mighty suggestive, but I'm not sure what to look at exactly.
> Perhaps apply "ldd" or local equivalent to those languages' .so files
> and see if they link to the same versions of indirectly-required
> libraries as Postgres is linking to?
>
> regards, tom lane
>
I have no experience with tcl, but I tried this in the two tclsh
versions installed no the system (8.6 and 8.7):
bsd@freebsd:~ $ tclsh8.7
% clock scan "1/26/2010"
time value too large/small to represent
bsd@freebsd:~ $ tclsh8.6
% clock scan "1/26/2010"
time value too large/small to represent
AFAIK this is what the tcl_date_week(2010,1,26) translates to.
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
