Thread: SELECT statement causing terminating the backend

SELECT statement causing terminating the backend

From
Radek Hrabčák
Date:
Short description: Problem with terminating the backend unexpectedly after
using SELECT statement (see bottom for more). It is not of high importance,
because for that select there is another working solution through using
outer join.

Version of Postgresql:
PostgreSQL 7.1 on i586-pc-linux-gnu, compiled by GCC egcs-2.91.66

Linux version:
Red Hat Linux release 6.0 (Hedwig)
Kernel 2.2.17
Umount of RAM: 200+ MB, procesor AMD Duron 750+ MHz

Description:
-------------------------------------------------------

create table tab_a (id INT, umount int, note text);
create table tab_b (id INT, note1 text);

insert into tab_a values(1,2,'item a');
insert into tab_a values(2,3,'item b');
insert into tab_a values(3,2,'item c');
insert into tab_a values(4,1,'item d');
insert into tab_b values(1,'A');
insert into tab_b values(3,'A');
insert into tab_b values(3,'B');

SELECT a.id, a.note,
SUM(a.umount) as total,       CASE WHEN EXISTS (SELECT 1 FROM tab_b b WHERE b.id = a.id)       THEN 1 ELSE 0 END AS
known_one
FROM tab_a a
WHERE NOT EXISTS (SELECT 1 FROM tab_b b   WHERE b.note1 = 'B'   AND b.id = a.id)
GROUP BY a.id,a.note, known_one;

--------------------------------------------------------------
will cause:

pqReadData() -- backend closed the channel unexpectedly.       This probably means the backend terminated abnormally
  before or while processing the request. 
The connection to the server was lost. Attempting reset: Failed.

---------------------------------------------------------------
and items from server log:

Server process (pid 1579) exited with status 139 at Wed Feb 27 12:12:24 2002
Terminating any active server processes...
Server processes were terminated at Wed Feb 27 12:12:24 2002
Reinitializing shared memory and semaphores
2002-02-27 12:12:24 DEBUG:  database system was interrupted at 2002-02-27
12:11:
09 CET
2002-02-27 12:12:24 DEBUG:  CheckPoint record at (36, 2792847308)
2002-02-27 12:12:24 DEBUG:  Redo record at (36, 2792847308); Undo record at
(0,
0); Shutdown TRUE
2002-02-27 12:12:24 DEBUG:  NextTransactionId: 24630725; NextOid: 160059859
2002-02-27 12:12:24 DEBUG:  database system was not properly shut down;
automati
c recovery in progress...
2002-02-27 12:12:24 DEBUG:  redo starts at (36, 2792847372)
The Data Base System is starting up
2002-02-27 12:12:24 DEBUG:  ReadRecord: record with zero len at (36,
2793638060)
2002-02-27 12:12:24 DEBUG:  redo done at (36, 2793638024)
2002-02-27 12:12:27 DEBUG:  database system is in production state

--
Radek Hrabcak, rhrabcak@czechin.cz

---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.323 / Virová báze: 180 - datum vydání: 8.2.2002


Re: SELECT statement causing terminating the backend

From
Tom Lane
Date:
Radek Hrabčák <rhrabcak@czechin.cz> writes:
> [ sub-SELECT in GROUP BY expression crashes backend ]

This is fixed in 7.2.
        regards, tom lane