From: | Palle Girgensohn <girgen(at)pingpong(dot)se> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | postgresql12-plpython: python3.6m crash database after ssh session close |
Date: | 2019-11-14 15:36:56 |
Message-ID: | 9F14DC76-9757-459B-94E0-687AA1EF4274@pingpong.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
I just received this bug report for postgresql 12 & plpython. There seems to be a problem with the default python-3.6 package for FreeBSD together with plpython. Any ideas how to pursue this?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241951 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241951>
Palle
--
12.0-RELEASE-p10
PostgreSQL 12
In pkg and ports postgresql uses libpython3.6m.so.1.0 by default and this is
buged for plpython I think.
Problem scenario:
1. Connect via ssh or use ssh tunnel via pgadmin4
2. Execute any plpython3u function via psql or pgadmin4 - it's will be OK
3. Close ssh session
4. Repeat steps 1-2 and now postgresql server will crash and autorecovery on
every call to function which use plpython3u until manualy "service postgresql
restart"
Some digging:
After each crash in log file:
LOG: server process (PID 17414) was terminated by signal 6: Abort trap
DETAIL: Failed process was running: select pyver();
LOG: database system was not properly shut down; automatic recovery in
progress
LOG: redo starts at 0/1787B98
LOG: invalid record length at 0/1787BD0: wanted 24, got 0
LOG: redo done at 0/1787B98
LOG: database system is ready to accept connections
Using gdb and postgres.core can see:
Program terminated with signal SIGABRT, Aborted.
#0 0x000000080142745a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0 0x000000080142745a in thr_kill () from /lib/libc.so.7
#1 0x0000000801425844 in raise () from /lib/libc.so.7
#2 0x0000000801398079 in abort () from /lib/libc.so.7
#3 0x000000080b103535 in Py_FatalError () from
/usr/local/lib/libpython3.6m.so.1.0
#4 0x000000080b1032eb in _Py_InitializeEx_Private () from
/usr/local/lib/libpython3.6m.so.1.0
#5 0x000000080af0c920 in PLy_initialize () from
/usr/local/lib/postgresql/plpython3.so
#6 0x000000080af0caaa in plpython3_call_handler () from
/usr/local/lib/postgresql/plpython3.so
#7 0x000000000063cf90 in ?? ()
#8 0x000000000066bad8 in ?? ()
#9 0x0000000000643c2d in standard_ExecutorRun ()
#10 0x000000000079d68d in ?? ()
#11 0x000000000079d272 in PortalRun ()
#12 0x000000000079c247 in ?? ()
#13 0x000000000079a27d in PostgresMain ()
#14 0x000000000071f836 in ?? ()
#15 0x000000000071eef0 in ?? ()
#16 0x000000000071c099 in PostmasterMain ()
#17 0x00000000006906de in main ()
Maybe problem in python version with "m" which mean compiled with
"--with-pymalloc", some version of memory allocation different from default.
Can't explain how ssh session affect on this.
I can fix it only with using different python version on make step
make PYTHON_VERSION=python3.8 install
---
I recevied this reply from Tom Lane:
That's just bizarre --- how could a previous session affect the state
of Python inside a new session? Is it possible the submitter put
plpython into shared_preload_libraries?
Is this reproducible?
The stack trace reminds me of
https://www.postgresql.org/message-id/flat/25662.1560896200%40sss.pgh.pa.us <https://www.postgresql.org/message-id/flat/25662.1560896200%40sss.pgh.pa.us>
although that's probably a red herring, because the mechanism there
seems quite NetBSD-specific.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-14 17:53:53 | Re: REINDEX CONCURRENTLY unexpectedly fails |
Previous Message | PG Bug reporting form | 2019-11-14 11:12:55 | BUG #16114: Repo is broken |