pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feeddikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
23+ messages / 4 participants
[nested] [flat]
* dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-18 13:11 Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 3 replies; 23+ messages in thread
From: Tomas Vondra @ 2023-09-18 13:11 UTC (permalink / raw)
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Hi,
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.
We did some investigation of an unrelated issue on dikkop about a month
ago [1], so it wasn't doing/reporting the buildfram stuff for a while.
After that I had to poweroff/move the machine, and unfortunately it
didn't boot after that - it's a rpi4 so maybe the SD card got damaged or
something, not sure.
I used the opportunity to install the new 14-BETA1 (instead of the
14-current snapshot), but unfortunately it started having issues :-(
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):
#0 0x00000000850e86c0 in OPENSSL_sk_insert ()
from /usr/local/lib/libcrypto.so.11
#1 0x00000000850a5848 in CRYPTO_set_ex_data ()
from /usr/local/lib/libcrypto.so.11
...
Full backtrace attached. I'm not sure what could possibly be causing
this, except maybe something in FreeBSD? Or maybe there's some confusion
about libraries? No idea.
The system is entirely new, there's only a handful of packages installed
(full list attached), and I don't think I did anything strange or much
different from the previous 14-current install.
Any ideas what might be causing this?
regards
[1]
https://www.postgresql.org/message-id/b2bc5c16-899e-ca99-26ed-e623b4259ec7%40enterprisedb.com
[2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2023-09-16%2021%3A10%3A45
[3]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2023-09-17%2000%3A01%3A42
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
(gdb) bt
#0 0x00000000850e86c0 in OPENSSL_sk_insert () from /usr/local/lib/libcrypto.so.11
#1 0x00000000850a5848 in CRYPTO_set_ex_data () from /usr/local/lib/libcrypto.so.11
#2 0x000000009fa6e698 in ossl_lib_ctx_generic_new (parent_ign=<optimized out>, ptr_ign=<optimized out>, ad=0x9fced5b8, index=1, argl_ign=<optimized out>, argp=<optimized out>) at /usr/src/crypto/openssl/crypto/context.c:333
#3 0x000000009fa716bc in ossl_crypto_alloc_ex_data_intern (class_index=class_index@entry=16, obj=0x0, obj@entry=0x8116e690, ad=ad@entry=0x9fced5b8, idx=1) at /usr/src/crypto/openssl/crypto/ex_data.c:456
#4 0x000000009fa6e360 in ossl_lib_ctx_get_data (ctx=ctx@entry=0x9fced5b0, index=index@entry=3, meth=<optimized out>) at /usr/src/crypto/openssl/crypto/context.c:428
#5 0x000000009fbcc69c in ossl_property_name (ctx=ctx@entry=0x9fced5b0, s=0x9f9949bc "provider", create=create@entry=1) at /usr/src/crypto/openssl/crypto/property/property_string.c:214
#6 0x000000009fbcbf14 in ossl_property_parse_init (ctx=ctx@entry=0x9fced5b0) at /usr/src/crypto/openssl/crypto/property/property_parse.c:557
#7 0x000000009fa6dc3c in context_init (ctx=0x9fced5b0) at /usr/src/crypto/openssl/crypto/context.c:102
#8 0x000000009fa6e0b0 in default_context_do_init () at /usr/src/crypto/openssl/crypto/context.c:155
#9 default_context_do_init_ossl_ () at /usr/src/crypto/openssl/crypto/context.c:152
#10 0x00000000896fccd8 in _thr_once (once_control=0x9fced780, init_routine=0x9fa6e088 <default_context_do_init_ossl_>) at /usr/src/lib/libthr/thread/thr_once.c:96
#11 0x00000000850ec218 in CRYPTO_THREAD_run_once () from /usr/local/lib/libcrypto.so.11
#12 0x000000009fa6e250 in get_thread_default_context () at /usr/src/crypto/openssl/crypto/context.c:166
#13 get_default_context () at /usr/src/crypto/openssl/crypto/context.c:174
#14 ossl_lib_ctx_get_concrete (ctx=0x0) at /usr/src/crypto/openssl/crypto/context.c:295
#15 ossl_lib_ctx_get_data (ctx=0x0, index=0, index@entry=-2129205248, meth=0x9fc9c778) at /usr/src/crypto/openssl/crypto/context.c:373
#16 0x000000009fb85cfc in get_evp_method_store (libctx=0x9fced5b0) at /usr/src/crypto/openssl/crypto/evp/evp_fetch.c:82
#17 inner_evp_generic_fetch (methdata=methdata@entry=0x8116e8e0, prov=0x0, prov@entry=0x8116e8c0, operation_id=operation_id@entry=1, name_id=0, name_id@entry=-2129205056, name=0x0, name@entry=0x8116e8c0 "\300\244\267\237",
properties=0x0, properties@entry=0x8116e8c0 "\300\244\267\237", new_method=0x9fb79fa0 <evp_md_from_algorithm>, up_ref_method=0x9fb7a49c <evp_md_up_ref>, free_method=0x9fb7a4c0 <evp_md_free>)
at /usr/src/crypto/openssl/crypto/evp/evp_fetch.c:270
#18 0x000000009fb86748 in evp_generic_do_all (libctx=0x0, operation_id=1, user_fn=0x9f7ee234, user_arg=0x8116e968, new_method=0x9fa6e6bc <ossl_lib_ctx_generic_free>, up_ref_method=0x0, free_method=0x3)
at /usr/src/crypto/openssl/crypto/evp/evp_fetch.c:654
#19 0x000000009f7ea91c in PyInit__hashlib () from /usr/local/lib/python3.9/lib-dynload/_hashlib.cpython-39.so
#20 0x00000000992abff8 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#21 0x00000000992ab860 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#22 0x00000000991feda4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#23 0x00000000992859f8 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#24 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#25 0x00000000991c0928 in _PyFunction_Vectorcall () from /usr/local/lib/libpython3.9.so.1.0
#26 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#27 0x000000009928567c in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#28 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#29 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#30 0x0000000099285660 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#31 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#32 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#33 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#34 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#35 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#36 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#37 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#38 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#39 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#40 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#41 0x00000000991c1ddc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#42 0x00000000991c1fb4 in _PyObject_CallMethodIdObjArgs () from /usr/local/lib/libpython3.9.so.1.0
#43 0x00000000992aa714 in PyImport_ImportModuleLevelObject () from /usr/local/lib/libpython3.9.so.1.0
#44 0x0000000099284448 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#45 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#46 0x0000000099280058 in PyEval_EvalCode () from /usr/local/lib/libpython3.9.so.1.0
#47 0x000000009927cc28 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#48 0x00000000991feda4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
--Type <RET> for more, q to quit, c to continue without paging--
#49 0x00000000992859f8 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#50 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#51 0x00000000991c0928 in _PyFunction_Vectorcall () from /usr/local/lib/libpython3.9.so.1.0
#52 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#53 0x000000009928567c in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#54 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#55 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#56 0x0000000099285660 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#57 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#58 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#59 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#60 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#61 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#62 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#63 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#64 0x00000000991c1ddc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#65 0x00000000991c1fb4 in _PyObject_CallMethodIdObjArgs () from /usr/local/lib/libpython3.9.so.1.0
#66 0x00000000992aa714 in PyImport_ImportModuleLevelObject () from /usr/local/lib/libpython3.9.so.1.0
#67 0x0000000099284448 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#68 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#69 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#70 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#71 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#72 0x0000000099280058 in PyEval_EvalCode () from /usr/local/lib/libpython3.9.so.1.0
#73 0x00000000967f360c in PLy_procedure_call (proc=proc@entry=0x553a88563120, kargs=<optimized out>, vargs=<optimized out>) at plpy_exec.c:1050
#74 0x00000000967f2dc0 in PLy_exec_function (fcinfo=fcinfo@entry=0x553a88569858, proc=0x553a88563120) at plpy_exec.c:104
#75 0x00000000967f4f44 in plpython3_call_handler (fcinfo=0x553a88569858) at plpy_main.c:270
#76 0x00000000006a8190 in ExecInterpExpr (state=0x553a88569770, econtext=<optimized out>, isnull=<optimized out>) at execExprInterp.c:680
#77 0x00000000006ded28 in ExecEvalExprSwitchContext (state=0x553a88569770, econtext=0x553a88569470, isNull=0x8117162c) at ../../../src/include/executor/executor.h:322
#78 ExecProject (projInfo=0x553a88569768) at ../../../src/include/executor/executor.h:356
#79 ExecResult (pstate=<optimized out>) at nodeResult.c:136
#80 0x00000000006af9cc in ExecProcNode (node=0x553a88569358) at ../../../src/include/executor/executor.h:248
#81 ExecutePlan (estate=0x553a88569120, use_parallel_mode=<optimized out>, operation=CMD_SELECT, numberTuples=0, direction=<optimized out>, dest=0x553a88567d90, planstate=<optimized out>, sendTuples=<optimized out>,
execute_once=<optimized out>) at execMain.c:1632
#82 standard_ExecutorRun (queryDesc=0x553a87e3dd20, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:350
#83 0x000000000083bbf0 in PortalRunSelect (portal=portal@entry=0x553a87f2c120, forward=<optimized out>, count=0, count@entry=9223372036854775807, dest=dest@entry=0x553a88567d90) at pquery.c:921
#84 0x000000000083b814 in PortalRun (portal=portal@entry=0x553a87f2c120, count=9223372036854775807, isTopLevel=<optimized out>, run_once=<optimized out>, dest=dest@entry=0x553a88567d90, altdest=altdest@entry=0x553a88567d90,
qc=qc@entry=0x811719f0) at pquery.c:765
#85 0x000000000083aa48 in exec_simple_query (query_string=query_string@entry=0x553a87e1f120 "SELECT import_test_one('sha hash of this string');") at postgres.c:1238
#86 0x0000000000838470 in PostgresMain (argc=<optimized out>, argv=<optimized out>, argv@entry=0x553a87f13340, dbname=<optimized out>, username=<optimized out>) at postgres.c:4359
#87 0x00000000007accf4 in BackendRun (port=port@entry=0x553a87ecf000) at postmaster.c:4560
#88 0x00000000007ac394 in BackendStartup (port=0x553a87ecf000) at postmaster.c:4244
#89 ServerLoop () at postmaster.c:1742
#90 0x00000000007a9864 in PostmasterMain (argc=<optimized out>, argc@entry=3, argv=<optimized out>, argv@entry=0x81172938) at postmaster.c:1415
#91 0x0000000000703098 in main (argc=3, argv=0x81172938) at main.c:210
bash-5.2.15
bison-3.8.2,1
boost-libs-1.82.0_1
ca_root_nss-3.92
ccache-3.7.12_4
curl-8.2.1
expat-2.5.0
flex-2.6.4_2
gdb-13.1_3
gettext-0.22
gettext-runtime-0.22_1
gettext-tools-0.22
git-2.42.0
gmake-4.3_2
gmp-6.3.0
htop-3.2.2_1
icu-73.2,1
indexinfo-0.3.1
libedit-3.1.20221030,1
libffi-3.4.4
libgcrypt-1.10.2
libgpg-error-1.47
libiconv-1.17
libidn2-2.3.4
liblz4-1.9.4,1
libnghttp2-1.55.1_1
libpsl-0.21.2_3
libssh2-1.11.0,3
libtextstyle-0.22
libtommath-1.2.0_2
libunistring-1.1
libxml2-2.10.4
libxslt-1.1.37
m4-1.4.19,1
mpdecimal-2.5.1
mpfr-4.2.0_2,1
nano-7.2
ncurses-6.4
openssl-1.1.1v,1
p5-Authen-NTLM-1.09_1
p5-Authen-SASL-2.17
p5-B-Hooks-EndOfScope-0.26
p5-CGI-4.57
p5-Clone-0.46
p5-Data-OptList-0.114
p5-Digest-HMAC-1.04
p5-Dist-CheckConflicts-0.11_1
p5-Encode-Locale-1.05
p5-Error-0.17029
p5-File-Listing-6.16
p5-GSSAPI-0.28_2
p5-HTML-Parser-3.81
p5-HTML-Tagset-3.20_1
p5-HTTP-CookieJar-0.014
p5-HTTP-Cookies-6.10
p5-HTTP-Date-6.06
p5-HTTP-Message-6.44
p5-HTTP-Negotiate-6.01_1
p5-IO-HTML-1.004
p5-IO-Socket-IP-0.42
p5-IO-Socket-SSL-2.083_1
p5-IO-Tty-1.17
p5-IPC-Run-20220807.0
p5-LWP-MediaTypes-6.04
p5-LWP-Protocol-https-6.11
p5-Module-Implementation-0.09_1
p5-Module-Runtime-0.016
p5-Mozilla-CA-20230807
p5-Net-HTTP-6.23
p5-Net-SSLeay-1.92
p5-Package-Stash-0.40
p5-Package-Stash-XS-0.30
p5-Params-Util-1.102
p5-Safe-Isa-1.000010
p5-Sub-Exporter-0.990
p5-Sub-Exporter-Progressive-0.001013
p5-Sub-Install-0.929
p5-Test-Harness-3.47
p5-Test-LWP-UserAgent-0.030
p5-TimeDate-2.33,1
p5-Try-Tiny-0.31
p5-URI-5.19
p5-Variable-Magic-0.63
p5-WWW-RobotRules-6.02_1
p5-libwww-6.70
p5-namespace-clean-0.27
pcre2-10.42
perl5-5.34.1_3
perl5-devel-5.39.0.62_3
pkg-1.20.6
pkgconf-1.8.1,1
python-3.9_3,2
python3-3_3
python39-3.9.17
readline-8.2.1
screen-4.9.1
source-highlight-3.1.9_6
sudo-1.9.14p3
tcl87-8.7.a5_1
xml2c-20151019_2
xxhash-0.8.2
zstd-1.5.5
Attachments:
[text/plain] backtrace.txt (9.7K, ../../316d304a-1dcd-cea1-3d6c-27f794727a06@enterprisedb.com/2-backtrace.txt)
download | inline:
(gdb) bt
#0 0x00000000850e86c0 in OPENSSL_sk_insert () from /usr/local/lib/libcrypto.so.11
#1 0x00000000850a5848 in CRYPTO_set_ex_data () from /usr/local/lib/libcrypto.so.11
#2 0x000000009fa6e698 in ossl_lib_ctx_generic_new (parent_ign=<optimized out>, ptr_ign=<optimized out>, ad=0x9fced5b8, index=1, argl_ign=<optimized out>, argp=<optimized out>) at /usr/src/crypto/openssl/crypto/context.c:333
#3 0x000000009fa716bc in ossl_crypto_alloc_ex_data_intern (class_index=class_index@entry=16, obj=0x0, obj@entry=0x8116e690, ad=ad@entry=0x9fced5b8, idx=1) at /usr/src/crypto/openssl/crypto/ex_data.c:456
#4 0x000000009fa6e360 in ossl_lib_ctx_get_data (ctx=ctx@entry=0x9fced5b0, index=index@entry=3, meth=<optimized out>) at /usr/src/crypto/openssl/crypto/context.c:428
#5 0x000000009fbcc69c in ossl_property_name (ctx=ctx@entry=0x9fced5b0, s=0x9f9949bc "provider", create=create@entry=1) at /usr/src/crypto/openssl/crypto/property/property_string.c:214
#6 0x000000009fbcbf14 in ossl_property_parse_init (ctx=ctx@entry=0x9fced5b0) at /usr/src/crypto/openssl/crypto/property/property_parse.c:557
#7 0x000000009fa6dc3c in context_init (ctx=0x9fced5b0) at /usr/src/crypto/openssl/crypto/context.c:102
#8 0x000000009fa6e0b0 in default_context_do_init () at /usr/src/crypto/openssl/crypto/context.c:155
#9 default_context_do_init_ossl_ () at /usr/src/crypto/openssl/crypto/context.c:152
#10 0x00000000896fccd8 in _thr_once (once_control=0x9fced780, init_routine=0x9fa6e088 <default_context_do_init_ossl_>) at /usr/src/lib/libthr/thread/thr_once.c:96
#11 0x00000000850ec218 in CRYPTO_THREAD_run_once () from /usr/local/lib/libcrypto.so.11
#12 0x000000009fa6e250 in get_thread_default_context () at /usr/src/crypto/openssl/crypto/context.c:166
#13 get_default_context () at /usr/src/crypto/openssl/crypto/context.c:174
#14 ossl_lib_ctx_get_concrete (ctx=0x0) at /usr/src/crypto/openssl/crypto/context.c:295
#15 ossl_lib_ctx_get_data (ctx=0x0, index=0, index@entry=-2129205248, meth=0x9fc9c778) at /usr/src/crypto/openssl/crypto/context.c:373
#16 0x000000009fb85cfc in get_evp_method_store (libctx=0x9fced5b0) at /usr/src/crypto/openssl/crypto/evp/evp_fetch.c:82
#17 inner_evp_generic_fetch (methdata=methdata@entry=0x8116e8e0, prov=0x0, prov@entry=0x8116e8c0, operation_id=operation_id@entry=1, name_id=0, name_id@entry=-2129205056, name=0x0, name@entry=0x8116e8c0 "\300\244\267\237",
properties=0x0, properties@entry=0x8116e8c0 "\300\244\267\237", new_method=0x9fb79fa0 <evp_md_from_algorithm>, up_ref_method=0x9fb7a49c <evp_md_up_ref>, free_method=0x9fb7a4c0 <evp_md_free>)
at /usr/src/crypto/openssl/crypto/evp/evp_fetch.c:270
#18 0x000000009fb86748 in evp_generic_do_all (libctx=0x0, operation_id=1, user_fn=0x9f7ee234, user_arg=0x8116e968, new_method=0x9fa6e6bc <ossl_lib_ctx_generic_free>, up_ref_method=0x0, free_method=0x3)
at /usr/src/crypto/openssl/crypto/evp/evp_fetch.c:654
#19 0x000000009f7ea91c in PyInit__hashlib () from /usr/local/lib/python3.9/lib-dynload/_hashlib.cpython-39.so
#20 0x00000000992abff8 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#21 0x00000000992ab860 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#22 0x00000000991feda4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#23 0x00000000992859f8 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#24 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#25 0x00000000991c0928 in _PyFunction_Vectorcall () from /usr/local/lib/libpython3.9.so.1.0
#26 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#27 0x000000009928567c in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#28 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#29 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#30 0x0000000099285660 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#31 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#32 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#33 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#34 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#35 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#36 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#37 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#38 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#39 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#40 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#41 0x00000000991c1ddc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#42 0x00000000991c1fb4 in _PyObject_CallMethodIdObjArgs () from /usr/local/lib/libpython3.9.so.1.0
#43 0x00000000992aa714 in PyImport_ImportModuleLevelObject () from /usr/local/lib/libpython3.9.so.1.0
#44 0x0000000099284448 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#45 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#46 0x0000000099280058 in PyEval_EvalCode () from /usr/local/lib/libpython3.9.so.1.0
#47 0x000000009927cc28 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#48 0x00000000991feda4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
--Type <RET> for more, q to quit, c to continue without paging--
#49 0x00000000992859f8 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#50 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#51 0x00000000991c0928 in _PyFunction_Vectorcall () from /usr/local/lib/libpython3.9.so.1.0
#52 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#53 0x000000009928567c in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#54 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#55 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#56 0x0000000099285660 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#57 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#58 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#59 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#60 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#61 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#62 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#63 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#64 0x00000000991c1ddc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#65 0x00000000991c1fb4 in _PyObject_CallMethodIdObjArgs () from /usr/local/lib/libpython3.9.so.1.0
#66 0x00000000992aa714 in PyImport_ImportModuleLevelObject () from /usr/local/lib/libpython3.9.so.1.0
#67 0x0000000099284448 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#68 0x00000000991c09e4 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#69 0x00000000992882d0 in ?? () from /usr/local/lib/libpython3.9.so.1.0
#70 0x0000000099285700 in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.9.so.1.0
#71 0x0000000099288efc in ?? () from /usr/local/lib/libpython3.9.so.1.0
#72 0x0000000099280058 in PyEval_EvalCode () from /usr/local/lib/libpython3.9.so.1.0
#73 0x00000000967f360c in PLy_procedure_call (proc=proc@entry=0x553a88563120, kargs=<optimized out>, vargs=<optimized out>) at plpy_exec.c:1050
#74 0x00000000967f2dc0 in PLy_exec_function (fcinfo=fcinfo@entry=0x553a88569858, proc=0x553a88563120) at plpy_exec.c:104
#75 0x00000000967f4f44 in plpython3_call_handler (fcinfo=0x553a88569858) at plpy_main.c:270
#76 0x00000000006a8190 in ExecInterpExpr (state=0x553a88569770, econtext=<optimized out>, isnull=<optimized out>) at execExprInterp.c:680
#77 0x00000000006ded28 in ExecEvalExprSwitchContext (state=0x553a88569770, econtext=0x553a88569470, isNull=0x8117162c) at ../../../src/include/executor/executor.h:322
#78 ExecProject (projInfo=0x553a88569768) at ../../../src/include/executor/executor.h:356
#79 ExecResult (pstate=<optimized out>) at nodeResult.c:136
#80 0x00000000006af9cc in ExecProcNode (node=0x553a88569358) at ../../../src/include/executor/executor.h:248
#81 ExecutePlan (estate=0x553a88569120, use_parallel_mode=<optimized out>, operation=CMD_SELECT, numberTuples=0, direction=<optimized out>, dest=0x553a88567d90, planstate=<optimized out>, sendTuples=<optimized out>,
execute_once=<optimized out>) at execMain.c:1632
#82 standard_ExecutorRun (queryDesc=0x553a87e3dd20, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:350
#83 0x000000000083bbf0 in PortalRunSelect (portal=portal@entry=0x553a87f2c120, forward=<optimized out>, count=0, count@entry=9223372036854775807, dest=dest@entry=0x553a88567d90) at pquery.c:921
#84 0x000000000083b814 in PortalRun (portal=portal@entry=0x553a87f2c120, count=9223372036854775807, isTopLevel=<optimized out>, run_once=<optimized out>, dest=dest@entry=0x553a88567d90, altdest=altdest@entry=0x553a88567d90,
qc=qc@entry=0x811719f0) at pquery.c:765
#85 0x000000000083aa48 in exec_simple_query (query_string=query_string@entry=0x553a87e1f120 "SELECT import_test_one('sha hash of this string');") at postgres.c:1238
#86 0x0000000000838470 in PostgresMain (argc=<optimized out>, argv=<optimized out>, argv@entry=0x553a87f13340, dbname=<optimized out>, username=<optimized out>) at postgres.c:4359
#87 0x00000000007accf4 in BackendRun (port=port@entry=0x553a87ecf000) at postmaster.c:4560
#88 0x00000000007ac394 in BackendStartup (port=0x553a87ecf000) at postmaster.c:4244
#89 ServerLoop () at postmaster.c:1742
#90 0x00000000007a9864 in PostmasterMain (argc=<optimized out>, argc@entry=3, argv=<optimized out>, argv@entry=0x81172938) at postmaster.c:1415
#91 0x0000000000703098 in main (argc=3, argv=0x81172938) at main.c:210
[text/plain] packages.txt (1.8K, ../../316d304a-1dcd-cea1-3d6c-27f794727a06@enterprisedb.com/3-packages.txt)
download | inline:
bash-5.2.15
bison-3.8.2,1
boost-libs-1.82.0_1
ca_root_nss-3.92
ccache-3.7.12_4
curl-8.2.1
expat-2.5.0
flex-2.6.4_2
gdb-13.1_3
gettext-0.22
gettext-runtime-0.22_1
gettext-tools-0.22
git-2.42.0
gmake-4.3_2
gmp-6.3.0
htop-3.2.2_1
icu-73.2,1
indexinfo-0.3.1
libedit-3.1.20221030,1
libffi-3.4.4
libgcrypt-1.10.2
libgpg-error-1.47
libiconv-1.17
libidn2-2.3.4
liblz4-1.9.4,1
libnghttp2-1.55.1_1
libpsl-0.21.2_3
libssh2-1.11.0,3
libtextstyle-0.22
libtommath-1.2.0_2
libunistring-1.1
libxml2-2.10.4
libxslt-1.1.37
m4-1.4.19,1
mpdecimal-2.5.1
mpfr-4.2.0_2,1
nano-7.2
ncurses-6.4
openssl-1.1.1v,1
p5-Authen-NTLM-1.09_1
p5-Authen-SASL-2.17
p5-B-Hooks-EndOfScope-0.26
p5-CGI-4.57
p5-Clone-0.46
p5-Data-OptList-0.114
p5-Digest-HMAC-1.04
p5-Dist-CheckConflicts-0.11_1
p5-Encode-Locale-1.05
p5-Error-0.17029
p5-File-Listing-6.16
p5-GSSAPI-0.28_2
p5-HTML-Parser-3.81
p5-HTML-Tagset-3.20_1
p5-HTTP-CookieJar-0.014
p5-HTTP-Cookies-6.10
p5-HTTP-Date-6.06
p5-HTTP-Message-6.44
p5-HTTP-Negotiate-6.01_1
p5-IO-HTML-1.004
p5-IO-Socket-IP-0.42
p5-IO-Socket-SSL-2.083_1
p5-IO-Tty-1.17
p5-IPC-Run-20220807.0
p5-LWP-MediaTypes-6.04
p5-LWP-Protocol-https-6.11
p5-Module-Implementation-0.09_1
p5-Module-Runtime-0.016
p5-Mozilla-CA-20230807
p5-Net-HTTP-6.23
p5-Net-SSLeay-1.92
p5-Package-Stash-0.40
p5-Package-Stash-XS-0.30
p5-Params-Util-1.102
p5-Safe-Isa-1.000010
p5-Sub-Exporter-0.990
p5-Sub-Exporter-Progressive-0.001013
p5-Sub-Install-0.929
p5-Test-Harness-3.47
p5-Test-LWP-UserAgent-0.030
p5-TimeDate-2.33,1
p5-Try-Tiny-0.31
p5-URI-5.19
p5-Variable-Magic-0.63
p5-WWW-RobotRules-6.02_1
p5-libwww-6.70
p5-namespace-clean-0.27
pcre2-10.42
perl5-5.34.1_3
perl5-devel-5.39.0.62_3
pkg-1.20.6
pkgconf-1.8.1,1
python-3.9_3,2
python3-3_3
python39-3.9.17
readline-8.2.1
screen-4.9.1
source-highlight-3.1.9_6
sudo-1.9.14p3
tcl87-8.7.a5_1
xml2c-20151019_2
xxhash-0.8.2
zstd-1.5.5
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-18 18:52 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
2 siblings, 1 reply; 23+ messages in thread
From: Tom Lane @ 2023-09-18 18:52 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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.
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
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2023-09-18%2013%3A59%3A40
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-18 20:41 Thomas Munro <thomas.munro@gmail.com>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
2 siblings, 0 replies; 23+ messages in thread
From: Thomas Munro @ 2023-09-18 20:41 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
IDK, but I tried installing tcl87 as you showed in packages.txt, and
REL_11_STABLE said:
checking for tclsh... no
checking for tcl... no
checking for tclsh8.6... no
checking for tclsh86... no
checking for tclsh8.5... no
checking for tclsh85... no
checking for tclsh8.4... no
checking for tclsh84... no
configure: error: Tcl shell not found
It seems like our configure stuff knows only about older tcl, so how
did you get past that?
The other thing that springs to mind, without any particular theory,
is that FreeBSD 14 switched to OpenSSL 3 (but hadn't done so yet in
your old current snapshot).
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-18 23:45 Michael Paquier <michael@paquier.xyz>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
2 siblings, 1 reply; 23+ messages in thread
From: Michael Paquier @ 2023-09-18 23:45 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Mon, Sep 18, 2023 at 03:11:27PM +0200, Tomas Vondra wrote:
> 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):
>
> #0 0x00000000850e86c0 in OPENSSL_sk_insert ()
> from /usr/local/lib/libcrypto.so.11
> #1 0x00000000850a5848 in CRYPTO_set_ex_data ()
> from /usr/local/lib/libcrypto.so.11
> ...
>
> Full backtrace attached. I'm not sure what could possibly be causing
> this, except maybe something in FreeBSD? Or maybe there's some confusion
> about libraries? No idea.
FWIW, I've seen such corrupted and time-sensitive stacks in the past
in the plpython tests in builds when python linked to a SSL library
different than what's linked with the backend. So that smells like a
packaging issue to me.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../ZQjhMFq_NdcAk2jJ@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-19 02:25 Thomas Munro <thomas.munro@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 23+ messages in thread
From: Thomas Munro @ 2023-09-19 02:25 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Sep 19, 2023 at 2:04 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Mon, Sep 18, 2023 at 03:11:27PM +0200, Tomas Vondra wrote:
> > 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):
> >
> > #0 0x00000000850e86c0 in OPENSSL_sk_insert ()
> > from /usr/local/lib/libcrypto.so.11
> > #1 0x00000000850a5848 in CRYPTO_set_ex_data ()
> > from /usr/local/lib/libcrypto.so.11
> > ...
> >
> > Full backtrace attached. I'm not sure what could possibly be causing
> > this, except maybe something in FreeBSD? Or maybe there's some confusion
> > about libraries? No idea.
>
> FWIW, I've seen such corrupted and time-sensitive stacks in the past
> in the plpython tests in builds when python linked to a SSL library
> different than what's linked with the backend. So that smells like a
> packaging issue to me.
Could it be confusion due to the presence of OpenSSL 3.0 in the
FreeBSD base system (/usr/include, /usr/lib) combined with the
presence of OpenSSL 1.1.1 installed with "pkg install openssl"
(/usr/local/include, /usr/local/lib)? Tomas, does it help if you "pkg
remove openssl"?
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-19 16:11 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Thomas Munro <thomas.munro@gmail.com>
0 siblings, 0 replies; 23+ messages in thread
From: Tomas Vondra @ 2023-09-19 16:11 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; Michael Paquier <michael@paquier.xyz>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/19/23 04:25, Thomas Munro wrote:
> On Tue, Sep 19, 2023 at 2:04 PM Michael Paquier <michael@paquier.xyz> wrote:
>> On Mon, Sep 18, 2023 at 03:11:27PM +0200, Tomas Vondra wrote:
>>> 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):
>>>
>>> #0 0x00000000850e86c0 in OPENSSL_sk_insert ()
>>> from /usr/local/lib/libcrypto.so.11
>>> #1 0x00000000850a5848 in CRYPTO_set_ex_data ()
>>> from /usr/local/lib/libcrypto.so.11
>>> ...
>>>
>>> Full backtrace attached. I'm not sure what could possibly be causing
>>> this, except maybe something in FreeBSD? Or maybe there's some confusion
>>> about libraries? No idea.
>>
>> FWIW, I've seen such corrupted and time-sensitive stacks in the past
>> in the plpython tests in builds when python linked to a SSL library
>> different than what's linked with the backend. So that smells like a
>> packaging issue to me.
>
> Could it be confusion due to the presence of OpenSSL 3.0 in the
> FreeBSD base system (/usr/include, /usr/lib) combined with the
> presence of OpenSSL 1.1.1 installed with "pkg install openssl"
> (/usr/local/include, /usr/local/lib)? Tomas, does it help if you "pkg
> remove openssl"?
Oh! That might be it - I didn't realize FreeBSD already has openssl 3.0
already included in the base system, so perhaps installing 1.1.1v leads
to some serious confusion ...
After some off-list discussion with Alvaro I tried removing the 1.1.1v
and installed the openssl31 package, which apparently resolved this (at
which point it ran into the unrelated tcl issue).
Still, this confusion seems rather unexpected, and I'm not sure if
having both 3.0 (from base) and 3.1 (from package) could lead to the
same confusion / crashes. Not sure if it's "our" problem ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-19 16:21 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 23+ messages in thread
From: Tomas Vondra @ 2023-09-19 16:21 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-19 16:45 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 23+ messages in thread
From: Tom Lane @ 2023-09-19 16:45 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> 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.
Oh, interesting. On my FreeBSD 13.1 arm64 system, it works:
$ tclsh8.6
% clock scan "1/26/2010"
1264482000
I am now suspicious that there's some locale effect that we have
not observed before (though why not?). What is the result of
the "locale" command on your box? Mine gives
$ locale
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-19 19:40 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 23+ messages in thread
From: Tomas Vondra @ 2023-09-19 19:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/19/23 18:45, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> 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.
>
> Oh, interesting. On my FreeBSD 13.1 arm64 system, it works:
>
> $ tclsh8.6
> % clock scan "1/26/2010"
> 1264482000
>
> I am now suspicious that there's some locale effect that we have
> not observed before (though why not?). What is the result of
> the "locale" command on your box? Mine gives
>
> $ locale
> LANG=C.UTF-8
> LC_CTYPE="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_ALL=
>
bsd@freebsd:~ $ locale
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_TIME="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_ALL=
bsd@freebsd:~ $ tclsh8.6
% clock scan "1/26/2010"
time value too large/small to represent
However, I wonder if there's something wrong with tcl itself,
considering this:
% clock format 1360558800 -format %D
02/11/2013
% clock scan 02/11/2013 -format %D
time value too large/small to represent
That's a bit strange - it seems tcl can format a timestamp, but then
can't read it back in for some reason ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-19 23:24 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 23+ messages in thread
From: Tom Lane @ 2023-09-19 23:24 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> bsd@freebsd:~ $ tclsh8.6
> % clock scan "1/26/2010"
> time value too large/small to represent
In hopes of replicating this, I tried installing FreeBSD 14-BETA2
aarch64 on my Pi 3B. This test case works fine:
$ tclsh8.6
% clock scan "1/26/2010"
1264482000
$ tclsh8.7
% clock scan "1/26/2010"
1264482000
and unsurprisingly, pltcl's regression tests pass. I surmise
that something is broken in BETA1 that they fixed in BETA2.
plpython works too, with the python 3.9 package (and no older
python).
However, all is not peachy, because plperl doesn't work.
Trying to CREATE EXTENSION either plperl or plperlu leads
to a libperl panic:
pl_regression=# create extension plperl;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
with this in the postmaster log:
panic: pthread_key_create failed
That message is certainly not ours, so it must be coming out of libperl.
Another thing that seemed strange is that ecpg's preproc.o takes
O(forever) to compile. I killed the build after observing that the
compiler had gotten to 40 minutes of CPU time, and redid that step
with PROFILE=-O0, which allowed it to compile in 20 seconds or so.
(I also tried -O1, but gave up after a few minutes.) This machine
can compile the main backend grammar in a minute or two, so there is
something very odd there.
I'm coming to the conclusion that 14-BETA is, well, beta grade.
I'll be interested to see if you get the same results when you
update to BETA2.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-20 17:59 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 23+ messages in thread
From: Tomas Vondra @ 2023-09-20 17:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/20/23 01:24, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> bsd@freebsd:~ $ tclsh8.6
>> % clock scan "1/26/2010"
>> time value too large/small to represent
>
> In hopes of replicating this, I tried installing FreeBSD 14-BETA2
> aarch64 on my Pi 3B. This test case works fine:
>
> $ tclsh8.6
> % clock scan "1/26/2010"
> 1264482000
>
> $ tclsh8.7
> % clock scan "1/26/2010"
> 1264482000
>
> and unsurprisingly, pltcl's regression tests pass. I surmise
> that something is broken in BETA1 that they fixed in BETA2.
>
> plpython works too, with the python 3.9 package (and no older
> python).
>
> However, all is not peachy, because plperl doesn't work.
> Trying to CREATE EXTENSION either plperl or plperlu leads
> to a libperl panic:
>
> pl_regression=# create extension plperl;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Succeeded.
>
> with this in the postmaster log:
>
> panic: pthread_key_create failed
>
> That message is certainly not ours, so it must be coming out of libperl.
>
> Another thing that seemed strange is that ecpg's preproc.o takes
> O(forever) to compile. I killed the build after observing that the
> compiler had gotten to 40 minutes of CPU time, and redid that step
> with PROFILE=-O0, which allowed it to compile in 20 seconds or so.
> (I also tried -O1, but gave up after a few minutes.) This machine
> can compile the main backend grammar in a minute or two, so there is
> something very odd there.
>
> I'm coming to the conclusion that 14-BETA is, well, beta grade.
> I'll be interested to see if you get the same results when you
> update to BETA2.
Thanks, I'll try that when I'll be at the office next week.
retards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-20 18:09 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 23+ messages in thread
From: Tomas Vondra @ 2023-09-20 18:09 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/20/23 19:59, Tomas Vondra wrote:
>
>
> On 9/20/23 01:24, Tom Lane wrote:
>> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>>> bsd@freebsd:~ $ tclsh8.6
>>> % clock scan "1/26/2010"
>>> time value too large/small to represent
>>
>> In hopes of replicating this, I tried installing FreeBSD 14-BETA2
>> aarch64 on my Pi 3B. This test case works fine:
>>
>> $ tclsh8.6
>> % clock scan "1/26/2010"
>> 1264482000
>>
>> $ tclsh8.7
>> % clock scan "1/26/2010"
>> 1264482000
>>
>> and unsurprisingly, pltcl's regression tests pass. I surmise
>> that something is broken in BETA1 that they fixed in BETA2.
>>
>> plpython works too, with the python 3.9 package (and no older
>> python).
>>
>> However, all is not peachy, because plperl doesn't work.
>> Trying to CREATE EXTENSION either plperl or plperlu leads
>> to a libperl panic:
>>
>> pl_regression=# create extension plperl;
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset: Succeeded.
>>
>> with this in the postmaster log:
>>
>> panic: pthread_key_create failed
>>
>> That message is certainly not ours, so it must be coming out of libperl.
>>
>> Another thing that seemed strange is that ecpg's preproc.o takes
>> O(forever) to compile. I killed the build after observing that the
>> compiler had gotten to 40 minutes of CPU time, and redid that step
>> with PROFILE=-O0, which allowed it to compile in 20 seconds or so.
>> (I also tried -O1, but gave up after a few minutes.) This machine
>> can compile the main backend grammar in a minute or two, so there is
>> something very odd there.
>>
>> I'm coming to the conclusion that 14-BETA is, well, beta grade.
>> I'll be interested to see if you get the same results when you
>> update to BETA2.
>
> Thanks, I'll try that when I'll be at the office next week.
>
FWIW when I disabled tcl, the tests pass (it's running with --nostatus
--nosend, so it's not visible on the buildfarm site). Including the
plperl stuff:
============== running regression test queries ==============
test plperl ... ok 397 ms
test plperl_lc ... ok 152 ms
test plperl_trigger ... ok 374 ms
test plperl_shared ... ok 163 ms
test plperl_elog ... ok 184 ms
test plperl_util ... ok 210 ms
test plperl_init ... ok 150 ms
test plperlu ... ok 117 ms
test plperl_array ... ok 228 ms
test plperl_call ... ok 189 ms
test plperl_transaction ... ok 412 ms
test plperl_plperlu ... ok 238 ms
======================
All 12 tests passed.
======================
I wonder if this got broken between BETA1 and BETA2.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-26 14:03 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 23+ messages in thread
From: Tomas Vondra @ 2023-09-26 14:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/20/23 20:09, Tomas Vondra wrote:
> On 9/20/23 19:59, Tomas Vondra wrote:
>>
>>
>> On 9/20/23 01:24, Tom Lane wrote:
>>> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>>>> bsd@freebsd:~ $ tclsh8.6
>>>> % clock scan "1/26/2010"
>>>> time value too large/small to represent
>>>
>>> In hopes of replicating this, I tried installing FreeBSD 14-BETA2
>>> aarch64 on my Pi 3B. This test case works fine:
>>>
>>> $ tclsh8.6
>>> % clock scan "1/26/2010"
>>> 1264482000
>>>
>>> $ tclsh8.7
>>> % clock scan "1/26/2010"
>>> 1264482000
>>>
>>> and unsurprisingly, pltcl's regression tests pass. I surmise
>>> that something is broken in BETA1 that they fixed in BETA2.
>>>
>>> plpython works too, with the python 3.9 package (and no older
>>> python).
>>>
>>> However, all is not peachy, because plperl doesn't work.
>>> Trying to CREATE EXTENSION either plperl or plperlu leads
>>> to a libperl panic:
>>>
>>> pl_regression=# create extension plperl;
>>> server closed the connection unexpectedly
>>> This probably means the server terminated abnormally
>>> before or while processing the request.
>>> The connection to the server was lost. Attempting reset: Succeeded.
>>>
>>> with this in the postmaster log:
>>>
>>> panic: pthread_key_create failed
>>>
>>> That message is certainly not ours, so it must be coming out of libperl.
>>>
>>> Another thing that seemed strange is that ecpg's preproc.o takes
>>> O(forever) to compile. I killed the build after observing that the
>>> compiler had gotten to 40 minutes of CPU time, and redid that step
>>> with PROFILE=-O0, which allowed it to compile in 20 seconds or so.
>>> (I also tried -O1, but gave up after a few minutes.) This machine
>>> can compile the main backend grammar in a minute or two, so there is
>>> something very odd there.
>>>
>>> I'm coming to the conclusion that 14-BETA is, well, beta grade.
>>> I'll be interested to see if you get the same results when you
>>> update to BETA2.
>>
>> Thanks, I'll try that when I'll be at the office next week.
>>
>
> FWIW when I disabled tcl, the tests pass (it's running with --nostatus
> --nosend, so it's not visible on the buildfarm site). Including the
> plperl stuff:
>
> ============== running regression test queries ==============
> test plperl ... ok 397 ms
> test plperl_lc ... ok 152 ms
> test plperl_trigger ... ok 374 ms
> test plperl_shared ... ok 163 ms
> test plperl_elog ... ok 184 ms
> test plperl_util ... ok 210 ms
> test plperl_init ... ok 150 ms
> test plperlu ... ok 117 ms
> test plperl_array ... ok 228 ms
> test plperl_call ... ok 189 ms
> test plperl_transaction ... ok 412 ms
> test plperl_plperlu ... ok 238 ms
>
> ======================
> All 12 tests passed.
> ======================
>
> I wonder if this got broken between BETA1 and BETA2.
>
Hmmm, I got to install BETA2 yesterday, but I still se the tcl failure:
select tcl_date_week(2010,1,26);
- tcl_date_week
----------------
- 04
-(1 row)
-
+ERROR: time value too large/small to represent
+CONTEXT: time value too large/small to represent
+ while executing
+"ConvertLocalToUTC $date[set date {}] $TZData($timezone) 2361222"
+ (procedure "FreeScan" line 86)
+ invoked from within
+"FreeScan $string $base $timezone $locale"
+ (procedure "::tcl::clock::scan" line 68)
+ invoked from within
+"::tcl::clock::scan 1/26/2010"
+ ("uplevel" body line 1)
+ invoked from within
+"uplevel 1 [info level 0]"
+ (procedure "::tcl::clock::scan" line 4)
+ invoked from within
+"clock scan "$2/$3/$1""
+ (procedure "__PLTcl_proc_55335" line 3)
+ invoked from within
+"__PLTcl_proc_55335 2010 1 26"
+in PL/Tcl function "tcl_date_week"
select tcl_date_week(2001,10,24);
I wonder what's the difference between the systems ... All I did was
writing the BETA2 image to SD card, and install a couple packages:
pkg install xml2c libxslt gettext-tools ccache tcl tcl87 \
p5-Test-Harness p5-IPC-Run gmake htop bash screen \
python tcl86 nano p5-Test-LWP-UserAgent \
p5-LWP-Protocol-https
And then
perl ./run_branches.pl --run-all --nosend --nostatus --verbose
with the buildfarm config used by dikkop.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-26 21:50 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 2 replies; 23+ messages in thread
From: Tom Lane @ 2023-09-26 21:50 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> Hmmm, I got to install BETA2 yesterday, but I still se the tcl failure:
Huh. I'm baffled as to what's up there. Is it possible that this is
actually a hardware-based difference? I didn't think there was much
difference between Pi 3B and Pi 4, but we're running out of other
explanations.
> I wonder what's the difference between the systems ... All I did was
> writing the BETA2 image to SD card, and install a couple packages:
I reinstalled BETA3, since that's out now, but see no change in
behavior.
I did discover that plperl works for me after adding --with-openssl
to the configure options. Not sure if it's worth digging any further
than that.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-27 09:06 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 23+ messages in thread
From: Tomas Vondra @ 2023-09-27 09:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/26/23 23:50, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> Hmmm, I got to install BETA2 yesterday, but I still se the tcl failure:
>
> Huh. I'm baffled as to what's up there. Is it possible that this is
> actually a hardware-based difference? I didn't think there was much
> difference between Pi 3B and Pi 4, but we're running out of other
> explanations.
>
Hmm, yeah. Which FreeBSD image did you install? armv7 or aarch64?
>> I wonder what's the difference between the systems ... All I did was
>> writing the BETA2 image to SD card, and install a couple packages:
>
> I reinstalled BETA3, since that's out now, but see no change in
> behavior.
>
> I did discover that plperl works for me after adding --with-openssl
> to the configure options. Not sure if it's worth digging any further
> than that.
>
No idea. Seems broken, but no time to investigate further at the moment.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-27 13:38 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
0 siblings, 1 reply; 23+ messages in thread
From: Tom Lane @ 2023-09-27 13:38 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 9/26/23 23:50, Tom Lane wrote:
>> Huh. I'm baffled as to what's up there. Is it possible that this is
>> actually a hardware-based difference? I didn't think there was much
>> difference between Pi 3B and Pi 4, but we're running out of other
>> explanations.
> Hmm, yeah. Which FreeBSD image did you install? armv7 or aarch64?
https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-arm64-aarch64...
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-27 19:33 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 23+ messages in thread
From: Tomas Vondra @ 2023-09-27 19:33 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/27/23 15:38, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> On 9/26/23 23:50, Tom Lane wrote:
>>> Huh. I'm baffled as to what's up there. Is it possible that this is
>>> actually a hardware-based difference? I didn't think there was much
>>> difference between Pi 3B and Pi 4, but we're running out of other
>>> explanations.
>
>> Hmm, yeah. Which FreeBSD image did you install? armv7 or aarch64?
>
> https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-arm64-aarch64...
>
Thanks, that's the image I've used. This is really strange ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-29 22:05 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
1 sibling, 0 replies; 23+ messages in thread
From: Tom Lane @ 2023-09-29 22:05 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 9/27/23 15:38, Tom Lane wrote:
>> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>>> Hmm, yeah. Which FreeBSD image did you install? armv7 or aarch64?
>> https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-BETA3-arm64-aarch64...
> Thanks, that's the image I've used. This is really strange ...
I've now laid my hands on a Pi 4B, and with that exact same SD card
plugged in, I get the same results I did with the 3B+: pltcl
regression tests pass, and so does the manual check with tclsh8.[67].
So it seems like the "different CPU" theory doesn't survive contact
with reality either.
I'm completely baffled, but I do notice that "clock scan" without
a -format option is deprecated according to the Tcl man page.
Maybe we should stop relying on deprecated behavior and put in
a -format option?
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-29 23:25 Thomas Munro <thomas.munro@gmail.com>
parent: Tomas Vondra <tomas.vondra@enterprisedb.com>
1 sibling, 2 replies; 23+ messages in thread
From: Thomas Munro @ 2023-09-29 23:25 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Does the image lack a /etc/localtime file/link, but perhaps one of you
did something to create it?
This came up with the CI image:
https://www.postgresql.org/message-id/flat/20230731191510.pebqeiuo2sbmlcfh%40awork3.anarazel.de
Also mentioned at: https://wiki.tcl-lang.org/page/clock+scan
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-29 23:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: Thomas Munro <thomas.munro@gmail.com>
1 sibling, 1 reply; 23+ messages in thread
From: Tom Lane @ 2023-09-29 23:57 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Thomas Munro <thomas.munro@gmail.com> writes:
> Does the image lack a /etc/localtime file/link, but perhaps one of you
> did something to create it?
Hah! I thought it had to be some sort of locale effect, but I failed
to think of that as a contributor :-(. My installation does have
/etc/localtime, and removing it duplicates Tomas' syndrome.
I also find that if I add "-gmt 1" to the clock invocation, it's happy
with or without /etc/localtime. So I think we should modify the test
case to use that to reduce its environmental sensitivity. Will
go make it so.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-09-30 00:46 Tom Lane <tgl@sss.pgh.pa.us>
parent: Thomas Munro <thomas.munro@gmail.com>
1 sibling, 0 replies; 23+ messages in thread
From: Tom Lane @ 2023-09-30 00:46 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Thomas Munro <thomas.munro@gmail.com> writes:
> This came up with the CI image:
> https://www.postgresql.org/message-id/flat/20230731191510.pebqeiuo2sbmlcfh%40awork3.anarazel.de
BTW, after re-reading that thread, I think the significant
difference is that these FreeBSD images don't force you to
select a timezone during setup, unlike what I recall seeing
when installing x86_64 FreeBSD. You're not forced to run
bsdconfig at all, and even if you do it doesn't make you
enter the sub-menu where you can pick a timezone. I recall
that I did do that while setting mine up, but I'll bet
Tomas skipped it. I'm not sure at this point whether FreeBSD
changed behavior since 13.x, or this is a difference between
their preferred installation processes for x86 vs. ARM.
But in any case, it's clearly easier to get into the
no-/etc/localtime state with these systems than I thought
before.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2023-10-04 11:04 Tomas Vondra <tomas.vondra@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 23+ messages in thread
From: Tomas Vondra @ 2023-10-04 11:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Thomas Munro <thomas.munro@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On 9/30/23 01:57, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
>> Does the image lack a /etc/localtime file/link, but perhaps one of you
>> did something to create it?
>
> Hah! I thought it had to be some sort of locale effect, but I failed
> to think of that as a contributor :-(. My installation does have
> /etc/localtime, and removing it duplicates Tomas' syndrome.
>
> I also find that if I add "-gmt 1" to the clock invocation, it's happy
> with or without /etc/localtime. So I think we should modify the test
> case to use that to reduce its environmental sensitivity. Will
> go make it so.
>
FWIW I've defined the timezone (copying it into /etc/localtime), and
that seems to have resolved the issue (well, maybe it's the "-gmt 1"
tweak, not sure).
I wonder how come it worked with the earlier image - I don't recall
defining the timezone (AFAIK I only did the bare minimum to get it
working), but maybe I did.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1)
@ 2025-08-08 22:27 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 23+ messages in thread
From: Tom Lane @ 2025-08-08 22:27 UTC (permalink / raw)
To: Tomas Vondra <tomas.vondra@enterprisedb.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
[ resurrecting an old thread ]
I wrote:
> I did discover that plperl works for me after adding --with-openssl
> to the configure options. Not sure if it's worth digging any further
> than that.
FYI, I just observed this exact same behavior (PL/Perl fails with
a panic inside libperl if you build it without --with-openssl)
on FreeBSD 13.5 x86 (32-bit). So that wasn't new in FreeBSD 14,
and it's not ARM-specific.
I'm still unexcited about trying to track down the precise cause,
but I thought this might be useful info to have in the archives.
regards, tom lane
^ permalink raw reply [nested|flat] 23+ messages in thread
end of thread, other threads:[~2025-08-08 22:27 UTC | newest]
Thread overview: 23+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-09-18 13:11 dikkop seems unhappy because of openssl stuff (FreeBSD 14-BETA1) Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-18 18:52 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-19 16:21 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-19 16:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-19 19:40 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-19 23:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-20 17:59 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-20 18:09 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-26 14:03 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-26 21:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-27 09:06 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-27 13:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-27 19:33 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-29 22:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-29 23:25 ` Thomas Munro <thomas.munro@gmail.com>
2023-09-29 23:57 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-10-04 11:04 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
2023-09-30 00:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-08-08 22:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2023-09-18 20:41 ` Thomas Munro <thomas.munro@gmail.com>
2023-09-18 23:45 ` Michael Paquier <michael@paquier.xyz>
2023-09-19 02:25 ` Thomas Munro <thomas.munro@gmail.com>
2023-09-19 16:11 ` Tomas Vondra <tomas.vondra@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox