Backend crashes on select ... union
От | Michael Bussmann |
---|---|
Тема | Backend crashes on select ... union |
Дата | |
Msg-id | 19980307170119.37927@goliath.mb.priv обсуждение исходный текст |
Ответы |
Re: [HACKERS] Backend crashes on select ... union
|
Список | pgsql-hackers |
Hi there! I played around with subselects and union and noticed that issuing strange statements can make the backend crash. The problem is that other clients connected to the same db get disconnected as well. I issued the following statement by mistake. (x1 is a table consisting only of one int4 value): select * from x1 union select * from pg_user; This crashes the backend. Postmaster (-d 2) says: > NOTICE: Message from PostgreSQL backend: > The Postmaster has informed me that some other backend died > abnormally and possibly corrupted shared memory. > I have rolled back the current transaction and am going to > terminate your database system connection and exit. > Please reconnect to the database system and repeat your query. Having nothing to lose, I typed: create table x1 (a text, b int4); create table x2 (c int4, d int4); insert into x1 values ('Test', '123'); insert into x2 values (1,2); select * from x1 union select * from x2; FATAL: unrecognized data from the backend. It probably dumped core. FATAL: unrecognized data from the backend. It probably dumped core. postmaster prints: > Too Large Allocation Request("!(0 < (size) && (size) <= > (0xfffffff)):size=-2 [0xfffffffe]", File: "mcxt.c", Line: 232) > ProcessQuery() at Sat Mar 7 16:45:48 1998 > > !(0 < (size) && (size) <= (0xfffffff)) (0) > NOTICE: Message from ... [same as above] Is there anything one can do to stop postgres from breaking all connections except telling your users not to type such useless statements? TIA MfG MB PS: I noticed that NO_ASSERT_CHECKING is undef'ed by default (so assert checking is enabled) and will only be defined if you specify either --enable-cassert or --disable-cassert. The INSTALL file, however, says assert checking is disabled by default (so NO_ASSERT_CHECKING should be set). Am I confusing something, or is it configure that gets confused? -- Michael Bussmann <bus@fgan.de> [Tel.: +49 228 9435 211; Fax: +49 228 348953] Today's Excuse: static from plastic slide rules
В списке pgsql-hackers по дате отправления: