Re: Segmentation fault.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrei N(dot)Sobchuck" <andreis(at)itware(dot)com(dot)ua>
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: Segmentation fault.
Date: 2000-08-19 03:08:07
Message-ID: 21376.966654487@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Andrei N.Sobchuck" <andrei(at)mart(dot)cherkassy(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2000-08-19 03:27:09 Re: serial field dump bug
Previous Message Tom Lane 2000-08-19 02:59:16 Re: date bug (again)