Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group