SELECT statement causing terminating the backend

Поиск
Список
Период
Сортировка
От Radek Hrabčák
Тема SELECT statement causing terminating the backend
Дата
Msg-id ECF6A65C93D5D311A22C004F4909B35D13BB75@czechin-server.brno.czechin.cz
обсуждение исходный текст
Ответы Re: SELECT statement causing terminating the backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
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


В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Michael G. Martin"
Дата:
Сообщение: Re: Indexes not always used after inserts/updates/vacuum analyze
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SELECT statement causing terminating the backend