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

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));

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

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));

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

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

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

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

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