On 11/20/18 3:06 PM, 066ce286@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