Backend crashes on select ... union - Mailing list pgsql-hackers

From Michael Bussmann
Subject Backend crashes on select ... union
Date
Msg-id 19980307170119.37927@goliath.mb.priv
Whole thread Raw
Responses Re: [HACKERS] Backend crashes on select ... union  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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 by date:

Previous
From: Patrick Scott Pierce
Date:
Subject: Re: [QUESTIONS] Error: ComputeDataSize
Next
From: Bruce Momjian
Date:
Subject: Re: your mail