Thread: Segmentation fault.

I've got a MSAccess client application. The application use ODBC to connect
to server.
Such as in my queries clauses like "some_boolean = TRUE" converts to
"some_boolean = 1",
I have to create a server procedure:
CREATE FUNCTION is_bool_eq_int(BOOL,INT4) RETURNS BOOL AS '
DECLARE
 sec BOOL;
BEGIN
 IF $2 = 0 THEN
      sec = ''f'';
 ELSE
     sec = ''t'';
 END IF;
 RETURN ($1 = sec);
 END;
' LANGUAGE  'plpgsql';

CREATE OPERATOR = (
    PROCEDURE = is_bool_eq_int,
    LEFTARG = BOOL,
    RIGHTARG = INT4,
    COMMUTATOR = '=',
    NEGATOR = '!=',
    RESTRICT = eqsel,
    JOIN = eqjoinsel
);
All works fine. But one query fails when I use search on boolean field.

Here is backtrace.
===============================================================
[nedvigimost2]# gdb /usr/local/pgsql-7.0.2/bin/postgres ./core
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...

warning: core file may not match specified executable file.
Core was generated by `/usr/local/pgsql/bin/postgres 192.168.1.67 an'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /usr/lib/libreadline.so.3...done.
Reading symbols from /lib/libtermcap.so.2...done.
Reading symbols from /usr/lib/libncurses.so.4...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/local/pgsql/lib/plpgsql.so...done.
#0  0x80a3ff0 in ExecEvalExpr ()
(gdb) bt
#0  0x80a3ff0 in ExecEvalExpr ()
#1  0x80ac0e8 in ExecSubPlan ()
#2  0x80a414f in ExecEvalExpr ()
#3  0x80a41be in ExecQual ()
#4  0x80a4649 in ExecScan ()
#5  0x80a7fd3 in ExecIndexScan ()
#6  0x80a2da9 in ExecProcNode ()
#7  0x80a93db in ExecNestLoop ()
#8  0x80a2dba in ExecProcNode ()
#9  0x80a93a1 in ExecNestLoop ()
#10 0x80a2dba in ExecProcNode ()
#11 0x80a93a1 in ExecNestLoop ()
#12 0x80a2dba in ExecProcNode ()
#13 0x80a93a1 in ExecNestLoop ()
#14 0x80a2dba in ExecProcNode ()
#15 0x80a1f2d in ExecutePlan ()
#16 0x80a144e in ExecutorRun ()
#17 0x81003d4 in ProcessQueryDesc ()
#18 0x8100461 in ProcessQuery ()
#19 0x80fecbc in pg_exec_query_dest ()
#20 0x80feb82 in pg_exec_query ()
#21 0x80ffd33 in PostgresMain ()
#22 0x80e8072 in DoBackend ()
#23 0x80e7c40 in BackendStartup ()
#24 0x80e6e49 in ServerLoop ()
#25 0x80e681e in PostmasterMain ()
#27 0x401069ab in __libc_start_main (main=0x80b2cf0 <main>, argc=8,
    argv=0xbffffbb4, init=0x80645c8 <_init>, fini=0x8145984 <_fini>,
    rtld_fini=0x4000ad00 <_dl_fini>, stack_end=0xbffffbac)
    at ../sysdeps/generic/libc-start.c:92
(gdb)

"Andrei N.Sobchuck" <andrei@mart.cherkassy.ua> writes:
> But one query fails when I use search on boolean field.

What's the query exactly?  I don't see any evidence in your backtrace
that the function is being invoked, so I doubt that has anything to do
with the problem.

            regards, tom lane

> "Andrei N.Sobchuck" <andrei@mart.cherkassy.ua> writes:
> > But one query fails when I use search on boolean field.
>
> What's the query exactly?  I don't see any evidence in your backtrace
> that the function is being invoked, so I doubt that has anything to do
> with the problem.

I'm using PostgreSQL on linux 2.2.13, glibc 2.1.3, compiled by gcc 2.95.3
with --enable-multibyte=KOI8.

Below You can see an example of query that crashes backend. The query was
generated by MSAccess. It works fine without "tel" = 1 (tel is boolean). Or
with "tel"=1, but without EXISTS-subquery.
=======
SELECT "object"."id_object" FROM "object" WHERE (((((((("status" = 1 ) AND
("tel" = 1 ) ) ) ) ) AND NOT(EXISTS (SELECT "po"."id_person"  FROM
"person_object" "po" WHERE (("po"."id_person" = 17 ) AND ("po"."id_object" =
"object"."id_object" ) ) )) ))) ORDER BY "object"."komnat"
,"object"."tekushaja_cena"
=======
I have a try for reproducing the bug. I have done "SELECT * INTO o FROM
object" and then I've executed the query with "o" (not "object") as source
table. Backend was not terminated. And more. The query on "object" table
works without any problems (in that session).
At now, I quit from "psql" and then run it again. Oops. Executing the query
on table named "object" terminate the backend. (But, after executing the
query on "o"-table, the query on "object" works fine. In current session.).


P.S.Is another way to work with boolean type field from MS Access?

> regards, tom lane
>
>

"Andrei N.Sobchuck" <andrei@mart.cherkassy.ua> writes:
> SELECT "object"."id_object" FROM "object" WHERE (((((((("status" = 1 ) AND
> ("tel" = 1 ) ) ) ) ) AND NOT(EXISTS (SELECT "po"."id_person"  FROM
> "person_object" "po" WHERE (("po"."id_person" = 17 ) AND ("po"."id_object" =
> "object"."id_object" ) ) )) ))) ORDER BY "object"."komnat"
> ,"object"."tekushaja_cena"
> =======
> I have a try for reproducing the bug. I have done "SELECT * INTO o FROM
> object" and then I've executed the query with "o" (not "object") as source
> table. Backend was not terminated. And more. The query on "object" table
> works without any problems (in that session).
> At now, I quit from "psql" and then run it again. Oops. Executing the query
> on table named "object" terminate the backend. (But, after executing the
> query on "o"-table, the query on "object" works fine. In current session.).

Interesting.  I couldn't duplicate this here (using guessed-at field
types of all 'int').  Can you get a stack backtrace from the crashed
backend?  It should leave a corefile in the database directory.

            regards, tom lane