On 11/20/18 3:06 PM, 066ce...@free.fr wrote:
Hi,
When gdb will be active, then use command c, and then run query in session. gdb
should to catch segfault.
Thank you very much. It's been helpfull.
BTW behaviour is strange. When I'm executing following, I do have always a SEGV
:
psql (11.1)
Type "help" for help.
herve=# CREATE OR REPLACE FUNCTION public.test_bug2(text,integer,timestamp with
time zone)
herve-# RETURNS integer
herve-#
herve-# AS '
herve'#
herve'# select coalesce(max(id),1) from sact_v1.autocalls where label=$1
and machine_id=$2 and created_date=$3;
herve'# '
herve-# LANGUAGE sql;
CREATE FUNCTION
herve=# select test_bug2('BSM_CRITICAL_SYSLOG',18843,now());
The GDB session :
Continuing.
Program received signal SIGSEGV, Segmentation fault.
prepare_query_params (param_types=0x1c86ac8, param_values=0x1c86ac0,
param_exprs=0x1c86ab8, param_flinfo=0x1c86ab0, numParams=3,
fdw_exprs=0x1c6b5b8, node=0x1c792d8) at mysql_fdw.c:2139
2139 *param_types[i] = exprType(param_expr);
(gdb) bt
So which part of that expression triggers the segfault? Try printing the
different parts, i.e.
p i
p param_types[i]
It might be helpful to also install the debug package, which would give
us more readable backtraces.
BTW, considering the failure is in mysql_fdw.c, this very much seems
like a bug in mysql_fdw - have you tried reporting it through the
project github repository?
https://github.com/EnterpriseDB/mysql_fdw/issues
That's probably more likely to help, and even if we find a bug here we
can't really commit that (perhaps some of the mysql_fdw authors are
watching this list, but I'm not sure about that).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
