I have a query crashing the backend and leaving this message in the
server log...

What does exit status 139 mean?  Better still would be a pointer to some
documentation for error codes if such beast exists...

Regards,
Ed Loehr

Fri, 23 Jun 2000 13:16:13 -0500
Ed Loehr <eloehr@austin.rr.com>
Server process exited with status 139 (meaning?)
Ed Loehr writes:

> I have a query crashing the backend and leaving this message in the
> server log...
> What does exit status 139 mean?

The backend terminated because of a segmentation fault (note 139 = 128 +
11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
query.

> Better still would be a pointer to some documentation for error codes
> if such beast exists...

See wait(2). Of course we could also make the error message more
expressive.

-- 
Peter Eisentraut                  Sernanders vï¿½g 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Sun, 25 Jun 2000 03:01:18 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Server process exited with status 139 (meaning?)
Peter Eisentraut wrote:
> 
> Ed Loehr writes:
> 
> > I have a query crashing the backend and leaving this message in the
> > server log...
> > What does exit status 139 mean?
> 
> The backend terminated because of a segmentation fault (note 139 = 128 +
> 11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
> query.

I don't need help on this as I found workable queries for my purposes,
but here is a simplified core-dumper (7.0beta3) for posterity...

Regards,
Ed Loehr

DROP TABLE foo;
CREATE TABLE foo (d date);
CREATE UNIQUE INDEX date_uidx ON foo(d);
CREATE UNIQUE INDEX datetime_uidx ON foo(datetime(d));
INSERT INTO foo (d) VALUES ('17-Jun-1995');
INSERT INTO foo (d) VALUES ('18-Jun-1995');
INSERT INTO foo (d) VALUES ('19-Jun-1995');
DROP TABLE bar;
DROP SEQUENCE bar_id_seq;
CREATE TABLE bar (
    id SERIAL, 
    start_time DATETIME,
    duration FLOAT
);
INSERT INTO bar (start_time, duration) VALUES ('17-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('18-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('19-Jun-1995', 3);
DROP TABLE baz;
DROP SEQUENCE baz_id_seq;
CREATE TABLE baz (
    id SERIAL, 
    bar_id DATETIME,
    duration FLOAT
);
INSERT INTO baz (bar_id, duration) SELECT id, duration FROM bar;
        
SELECT f.d, r.start_time::date, r.duration AS "r_dur",
       z.duration AS "z_dur", f.d,
       (r.start_time - '1 day'::interval)::date AS "leave",
       (r.start_time + (z.duration||' days')::interval)::date AS "return"
FROM foo f, activity r, activity_hr_need z
WHERE r.id = 2
  AND z.activity_id = 2
  AND (f.d = (r.start_time - '1 day'::interval)::date 
    OR f.d = (r.start_time + (z.duration||' days')::interval));

Sun, 25 Jun 2000 23:10:16 -0500
Ed Loehr <eloehr@austin.rr.com>
Re: Server process exited with status 139 (meaning?)
Ed Loehr <eloehr@austin.rr.com> writes:
> I don't need help on this as I found workable queries for my purposes,
> but here is a simplified core-dumper (7.0beta3) for posterity...

This doesn't come close to doing anything as-is, but even reading
between the lines ("activity"=>"bar" etc) and deleting references
to missing fields, I can't get a crash.  Possibly a bug fixed since
beta3?

			regards, tom lane

Mon, 26 Jun 2000 00:35:44 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Server process exited with status 139 (meaning?) 
Ed Loehr wrote:
> 
> Peter Eisentraut wrote:
> >
> > Ed Loehr writes:
> >
> > > I have a query crashing the backend and leaving this message in the
> > > server log...
> > > What does exit status 139 mean?
> >
> > The backend terminated because of a segmentation fault (note 139 = 128 +
> > 11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
> > query.
> 
> I don't need help on this as I found workable queries for my purposes,
> but here is a simplified core-dumper (7.0beta3) for posterity...

Oops.  A few typos in my last post.  Correction below (still
segfaulting):

DROP TABLE foo;
CREATE TABLE foo (d date);
CREATE UNIQUE INDEX date_uidx ON foo(d);
CREATE UNIQUE INDEX datetime_uidx ON foo(datetime(d));
INSERT INTO foo (d) VALUES ('17-Jun-1995');
INSERT INTO foo (d) VALUES ('18-Jun-1995');
INSERT INTO foo (d) VALUES ('19-Jun-1995');

DROP TABLE bar;
DROP SEQUENCE bar_id_seq;
CREATE TABLE bar (
    id SERIAL, 
    start_time DATETIME,
    duration FLOAT
);
INSERT INTO bar (start_time, duration) VALUES ('17-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('18-Jun-1995', 3);
INSERT INTO bar (start_time, duration) VALUES ('19-Jun-1995', 3);

DROP TABLE baz;
DROP SEQUENCE baz_id_seq;
CREATE TABLE baz (
    id SERIAL, 
    bar_id DATETIME,
    duration FLOAT
);
INSERT INTO baz (bar_id, duration) SELECT id, duration FROM bar;
        
-- Here's the offending query...
SELECT f.d, r.start_time::date, r.duration AS "r_dur",
       z.duration AS "z_dur", f.d,
       (r.start_time - '1 day'::interval)::date AS "leave",
       (r.start_time + (z.duration||' days')::interval)::date AS "return"
FROM foo f, bar r, baz z
WHERE r.id = 2
  AND z.bar_id = 2
  AND (f.d = (r.start_time - '1 day'::interval)::date 
    OR f.d = (r.start_time + (z.duration||' days')::interval));

Sun, 25 Jun 2000 23:56:24 -0500
Ed Loehr <eloehr@austin.rr.com>
Re: Server process exited with status 139 (meaning?)
Ed Loehr wrote:
> 
> > > > I have a query crashing the backend and leaving this message in the
> > > > server log...
> > > > What does exit status 139 mean?
> > >
> > > The backend terminated because of a segmentation fault (note 139 = 128 +
> > > 11, 11 = SIGSEGV). So it's definitely a bug and we'd need to see the
> > > query.
> >
> > I don't need help on this as I found workable queries for my purposes,
> > but here is a simplified core-dumper (7.0beta3) for posterity...
> 
> Oops.  A few typos in my last post.  Correction below (still
> segfaulting):
> 
> DROP TABLE foo;
> CREATE TABLE foo (d date);
> CREATE UNIQUE INDEX date_uidx ON foo(d);
> CREATE UNIQUE INDEX datetime_uidx ON foo(datetime(d));
> INSERT INTO foo (d) VALUES ('17-Jun-1995');
> INSERT INTO foo (d) VALUES ('18-Jun-1995');
> INSERT INTO foo (d) VALUES ('19-Jun-1995');
> 
> DROP TABLE bar;
> DROP SEQUENCE bar_id_seq;
> CREATE TABLE bar (
>     id SERIAL,
>     start_time DATETIME,
>     duration FLOAT
> );
> INSERT INTO bar (start_time, duration) VALUES ('17-Jun-1995', 3);
> INSERT INTO bar (start_time, duration) VALUES ('18-Jun-1995', 3);
> INSERT INTO bar (start_time, duration) VALUES ('19-Jun-1995', 3);
> 
> DROP TABLE baz;
> DROP SEQUENCE baz_id_seq;
> CREATE TABLE baz (
>     id SERIAL,
>     bar_id DATETIME,
             ^^^^^^^^^

One more typo:  'bar_id' should be of type INTEGER (and the crash
remains).

Regards,
Ed Loehr

>     duration FLOAT
> );
> INSERT INTO baz (bar_id, duration) SELECT id, duration FROM bar;
> 
> -- Here's the offending query...
> SELECT f.d, r.start_time::date, r.duration AS "r_dur",
>        z.duration AS "z_dur", f.d,
>        (r.start_time - '1 day'::interval)::date AS "leave",
>        (r.start_time + (z.duration||' days')::interval)::date AS "return"
> FROM foo f, bar r, baz z
> WHERE r.id = 2
>   AND z.bar_id = 2
>   AND (f.d = (r.start_time - '1 day'::interval)::date
>     OR f.d = (r.start_time + (z.duration||' days')::interval));

Mon, 26 Jun 2000 00:07:30 -0500
Ed Loehr <eloehr@austin.rr.com>
Re: Server process exited with status 139 (meaning?)
Tom Lane wrote:
> 
> Ed Loehr <eloehr@austin.rr.com> writes:
> > I don't need help on this as I found workable queries for my purposes,
> > but here is a simplified core-dumper (7.0beta3) for posterity...
> 
> This doesn't come close to doing anything as-is, but even reading
> between the lines ("activity"=>"bar" etc) and deleting references
> to missing fields, I can't get a crash.  Possibly a bug fixed since
> beta3?

I'll assume you tried my latest typo-free version on an HP box after
posting this and got the same results (i.e., nothing).  Maybe someone
else would care to verify on a Linux box?  I'm on RH 6.2 with dual
PIII's...

Regards,
Ed Loehr

Mon, 26 Jun 2000 00:25:10 -0500
Ed Loehr <eloehr@austin.rr.com>
Re: Server process exited with status 139 (meaning?)
> I'll assume you tried my latest typo-free version on an HP box after
> posting this and got the same results (i.e., nothing).  Maybe someone
> else would care to verify on a Linux box?  I'm on RH 6.2 with dual
> PIII's...

I see the latest being formally rejected down in the Executor. So
something is better than in the beta, but the plan being generated is
not quite right apparently.

                - Thomas

Mon, 26 Jun 2000 05:30:40 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Server process exited with status 139 (meaning?)
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I see the latest being formally rejected down in the Executor. So
> something is better than in the beta, but the plan being generated is
> not quite right apparently.

No sign of a problem here (using current sources).  Exactly which of
Ed's versions did you see a problem with, and what did you see exactly?

			regards, tom lane

Mon, 26 Jun 2000 02:51:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Server process exited with status 139 (meaning?) 
Ed Loehr wrote:
> > > I don't need help on this as I found workable queries for my purposes,
> > > but here is a simplified core-dumper (7.0beta3) for posterity...
> >

test=# -- Here's the offending query...
test=# SELECT f.d, r.start_time::date, r.duration AS "r_dur",
test-#        z.duration AS "z_dur", f.d,
test-#        (r.start_time - '1 day'::interval)::date AS "leave",
test-#        (r.start_time + (z.duration||' days')::interval)::date AS
"return"
test-# FROM foo f, bar r, baz z
test-# WHERE r.id = 2
test-#   AND z.bar_id = 2
test-#   AND (f.d = (r.start_time - '1 day'::interval)::date 
test(#     OR f.d = (r.start_time + (z.duration||' days')::interval));
     d      |  ?column?  | r_dur | z_dur |     d      |   leave    |  
return   
------------+------------+-------+-------+------------+------------+------------
 1995-06-17 | 1995-06-18 |     3 |     3 | 1995-06-17 | 1995-06-17 |
1995-06-21
(1 row)

test=# 
test=# explain SELECT f.d, r.start_time::date, r.duration AS "r_dur",
test-#        z.duration AS "z_dur", f.d,
test-#        (r.start_time - '1 day'::interval)::date AS "leave",
test-#        (r.start_time + (z.duration||' days')::interval)::date AS
"return"
test-# FROM foo f, bar r, baz z
test-# WHERE r.id = 2
test-#   AND z.bar_id = 2
test-#   AND (f.d = (r.start_time - '1 day'::interval)::date 
test(#     OR f.d = (r.start_time + (z.duration||' days')::interval));
NOTICE:  QUERY PLAN:

Nested Loop  (cost=0.00..5354.86 rows=1990 width=28)
  ->  Nested Loop  (cost=0.00..104.86 rows=100 width=24)
        ->  Seq Scan on baz z  (cost=0.00..22.50 rows=10 width=8)
        ->  Index Scan using bar_id_key on bar r  (cost=0.00..8.14
rows=10 width=16)
  ->  Seq Scan on foo f  (cost=0.00..20.00 rows=1000 width=4)

EXPLAIN
test=# select version();
                            version                            
---------------------------------------------------------------
 PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc 2.95.2
(1 row)


Works fine on my Debian 'woody' system on my laptop.


Also, looking at your other query:

test=#         
test=# -- Here's the offending query...
test=# SELECT f.d, r.start_time::date, r.duration AS "r_dur", z.duration
AS
test-# "z_dur"
test-# FROM foo f, bar r, baz z
test-# WHERE r.id = 2 
test-#   AND z.bar_id = 2
test-#   AND f.d = (r.start_time - '1 day'::interval)::date ;
 d | ?column? | r_dur | z_dur 
---+----------+-------+-------
(0 rows)

so no problem there either.  Looks like you should get a trade-in on
that beta3 :-)

Cheers,
				Andrew.
-- 
_____________________________________________________________________
            Andrew McMillan, e-mail: Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267

Mon, 26 Jun 2000 23:51:36 +1200
Andrew McMillan <Andrew@catalyst.net.nz>
Re: Server process exited with status 139 (meaning?)