cancel
Showing results for 
Search instead for 
Did you mean: 

Server crashes when 'numeric' data type is used on any plpython Function

Adventurer

Server crashes when 'numeric' data type is used on any plpython Function

# Steps to Reproduce
Install extension plpython3u
Create function using data type numeric as an input, may be unique input or in combination with other data types.
Use Function in query such as SELECT or UPDATE.

 

#Example
CREATE OR REPLACE FUNCTION network.test(number numeric)
RETURNS numeric
LANGUAGE 'plpython3u'
VOLATILE
PARALLEL UNSAFE
COST 100
AS $BODY$return number
$BODY$;

 

SELECT network.test(5);

 

#Additional Info
Installation made with PosgreSQL 12 EDB Windows Installer x64 on Windows 7.
Using python37.dll from Stack Builder installer (same package), issue was present with previous versions as well (dll had to be moved to System32 Folder for PosgreSQL to recognize it).
Issue could be reproduced as well in PostgreSQL 11 before update.
If inputs in functions are switched to text, text[], int, int[] they work without any problem.
Issue is not reproducible on Fedora 30 with python 3.7.4
https://www.postgresql.org/docs/12/plpython-data.html describes compatibility with a data type mapping to Decimal.

 

#Log Output
2019-10-20 13:21:59.116 PDT [2864] LOG: server process (PID 12560) was terminated by exception 0xC0000005
2019-10-20 13:21:59.116 PDT [2864] DETAIL: Failed process was running: SELECT network.test(5)
2019-10-20 13:21:59.116 PDT [2864] HINT: See C include file "ntstatus.h" for a description of the hexadecimal value.
2019-10-20 13:21:59.117 PDT [2864] LOG: terminating any other active server processes
2019-10-20 13:21:59.119 PDT [13156] WARNING: terminating connection because of crash of another server process
2019-10-20 13:21:59.119 PDT [13156] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2019-10-20 13:21:59.119 PDT [13156] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2019-10-20 13:21:59.121 PDT [7960] WARNING: terminating connection because of crash of another server process
2019-10-20 13:21:59.121 PDT [7960] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2019-10-20 13:21:59.121 PDT [7960] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2019-10-20 13:21:59.122 PDT [3040] WARNING: terminating connection because of crash of another server process
2019-10-20 13:21:59.122 PDT [3040] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2019-10-20 13:21:59.122 PDT [3040] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2019-10-20 13:21:59.131 PDT [2824] WARNING: terminating connection because of crash of another server process
2019-10-20 13:21:59.131 PDT [2824] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2019-10-20 13:21:59.131 PDT [2824] HINT: In a moment you should be able to reconnect to the database and repeat your command.
2019-10-20 13:21:59.174 PDT [2864] LOG: all server processes terminated; reinitializing
2019-10-20 13:21:59.233 PDT [10152] LOG: database system was interrupted; last known up at 2019-10-20 08:04:14 PDT
2019-10-20 13:22:00.523 PDT [7104] FATAL: the database system is in recovery mode
2019-10-20 13:22:00.894 PDT [13076] FATAL: the database system is in recovery mode
2019-10-20 13:22:02.009 PDT [8300] FATAL: the database system is in recovery mode
2019-10-20 13:22:02.973 PDT [12948] FATAL: the database system is in recovery mode
2019-10-20 13:22:03.612 PDT [12708] FATAL: the database system is in recovery mode
2019-10-20 13:22:04.924 PDT [9844] FATAL: the database system is in recovery mode
2019-10-20 13:22:05.564 PDT [3520] FATAL: the database system is in recovery mode
2019-10-20 13:22:05.962 PDT [8052] FATAL: the database system is in recovery mode
2019-10-20 13:22:06.898 PDT [1264] FATAL: the database system is in recovery mode
2019-10-20 13:22:06.960 PDT [9512] FATAL: the database system is in recovery mode
2019-10-20 13:22:07.534 PDT [9316] FATAL: the database system is in recovery mode
2019-10-20 13:22:07.981 PDT [13044] FATAL: the database system is in recovery mode
2019-10-20 13:22:08.051 PDT [9520] FATAL: the database system is in recovery mode
2019-10-20 13:22:08.898 PDT [10744] FATAL: the database system is in recovery mode
2019-10-20 13:22:08.957 PDT [12804] FATAL: the database system is in recovery mode
2019-10-20 13:22:09.526 PDT [9992] FATAL: the database system is in recovery mode
2019-10-20 13:22:09.973 PDT [9212] FATAL: the database system is in recovery mode
2019-10-20 13:22:10.029 PDT [10504] FATAL: the database system is in recovery mode
2019-10-20 13:22:10.904 PDT [9292] FATAL: the database system is in recovery mode
2019-10-20 13:22:10.978 PDT [9796] FATAL: the database system is in recovery mode
2019-10-20 13:22:11.534 PDT [10784] FATAL: the database system is in recovery mode
2019-10-20 13:22:11.959 PDT [8096] FATAL: the database system is in recovery mode
2019-10-20 13:22:12.023 PDT [12532] FATAL: the database system is in recovery mode
2019-10-20 13:22:12.900 PDT [12724] FATAL: the database system is in recovery mode
2019-10-20 13:22:13.066 PDT [8256] FATAL: the database system is in recovery mode
2019-10-20 13:22:13.998 PDT [4152] FATAL: the database system is in recovery mode
2019-10-20 13:22:14.008 PDT [3392] FATAL: the database system is in recovery mode
2019-10-20 13:22:14.902 PDT [9960] FATAL: the database system is in recovery mode
2019-10-20 13:22:15.538 PDT [12580] FATAL: the database system is in recovery mode
2019-10-20 13:22:16.958 PDT [10152] LOG: database system was not properly shut down; automatic recovery in progress
2019-10-20 13:22:17.000 PDT [10152] LOG: redo starts at 0/85D5338
2019-10-20 13:22:17.000 PDT [10152] LOG: invalid record length at 0/85D5418: wanted 24, got 0
2019-10-20 13:22:17.000 PDT [10152] LOG: redo done at 0/85D53E0
2019-10-20 13:22:17.264 PDT [2864] LOG: database system is ready to accept connections

3 REPLIES 3
EDB Team Member

Re: Server crashes when 'numeric' data type is used on any plpython Function

Hi Isaacag,

 

We are able reproduce this issue from our end as well and we are checking with Development team and will let you know with their feedback.

Adventurer

Re: Server crashes when 'numeric' data type is used on any plpython Function

In a reletad issue, the same installation has been made in Windows 10.

Server crash can be reproduced after trying to create a new plpython function of any data type.

 

# Log Output

2019-10-22 04:25:12.075 CDT [22972] LOG:  server process (PID 16420) was terminated by exception 0xC0000409
2019-10-22 04:25:12.075 CDT [22972] DETAIL:  Failed process was running: CREATE FUNCTION public.inc(IN num integer)
        RETURNS integer
        LANGUAGE 'plpython3u'
    AS $BODY$return num$BODY$;
2019-10-22 04:25:12.075 CDT [22972] HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.
2019-10-22 04:25:12.079 CDT [22972] LOG:  terminating any other active server processes
2019-10-22 04:25:12.086 CDT [20096] WARNING:  terminating connection because of crash of another server process
2019-10-22 04:25:12.086 CDT [20096] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2019-10-22 04:25:12.086 CDT [20096] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2019-10-22 04:25:12.113 CDT [24724] WARNING:  terminating connection because of crash of another server process
2019-10-22 04:25:12.113 CDT [24724] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2019-10-22 04:25:12.113 CDT [24724] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2019-10-22 04:25:12.122 CDT [22972] LOG:  all server processes terminated; reinitializing
2019-10-22 04:25:12.201 CDT [15716] LOG:  database system was interrupted; last known up at 2019-10-22 04:25:09 CDT
2019-10-22 04:25:12.595 CDT [15716] LOG:  database system was not properly shut down; automatic recovery in progress
EDB Team Member

Re: Server crashes when 'numeric' data type is used on any plpython Function

Hi Isaacag,

 

So the issue is with PYTHONHOME is not set properly. If we are using variable name as PYTHON_HOME and creating the function the database is getting crash and when using PYTHONHOME we are successfully able to create the function without any crash. Please refer the attached screenshots for your reference.

 

shouldn't be copying the dlls to System32 folder instead set the python specific environment variables as mentioned in the below link and screenshot. Copying dlls into System32 directory and not setting the system variables may also result into a crash.

 

And also verify the below link to set the PYTHONHOME and PATH and It's documented in the languagepack document.

https://www.enterprisedb.com/edb-docs/static/docs/postgresql/12/EDB_Postgres_Language_Pack_Guide_v1....

 

Hope this helps you.

 

plpython.pngPYTHONHOME Function Success

Screenshot 2019-11-05 at 7.51.52 PM.pngPYTHON_HOME Function Crash.