Обсуждение: Server process exited with status 139 (meaning?)
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
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)::dateAS "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 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)::dateAS "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 <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:
>
> > > > 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));
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) -> SeqScan 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