Thread: Re: PG crash on simple query, story continues

Re: PG crash on simple query, story continues

From
"Maksim Likharev"
Date:
I still having that same error on my simple query:
Tables has been rebuild, reindexed, and DB has been moved to another
computer,
worked for a while, and now aging same story.

We run PG 7.3

I repeat query:
SELECT p.docid FROM prod.t_documents AS p
 INNER JOIN t_tempdocs AS t
     ON p.docid = t.docid
         LEFT OUTER JOIN prod.t_refs AS ct
             ON ct.docid = p.docid;

here is a stack trace:
 00252174 AllocSetAlloc (3813b0, 15, 251fe0, 20, 0, ffbee2f8) + 194
 002532e4 MemoryContextAlloc (3813b0, 15, 11, 7efefeff, 81010100, ff00)
+ 68
 0020dc0c varcharin (ffbee378, ffbee378, 20dae4, 0, 0, ffbee3f0) + 128
 00243570 FunctionCall3 (ffbee4a8, 3c1ce8, 0, 324, 0, ffbee5c4) + 11c
 0023e6c4 get_attstatsslot (3d6410, 413, 324, 2, 0, ffbee5c4) + 2b0
 001f8cb4 scalarineqsel (3bb978, 42a, 0, 3bffa8, 40f0e8, 413) + 288
 001fb824 mergejoinscansel (3bb978, 3c0080, 3c0968, 3c0970, 0, 1) + 23c
 0014ef58 cost_mergejoin (40ef88, 3bb978, 3c1a50, 3c09f8, 3c1c28,
40f018) + c0
 0016a2f0 create_mergejoin_path (3bb978, 3c1420, 1, 3c1a50, 3c09f8,
3c1c28) + 14
8
 0015400c sort_inner_and_outer (3bb978, 3c1420, 3c0470, 3c04f8, 3c1c28,
3c1c10)
+ 200
 00153d94 add_paths_to_joinrel (3bb978, 3c1420, 3c0470, 3c04f8, 1,
3c1c28) + 98
 00155790 make_join_rel (3bb978, 3c0470, 3c04f8, 1, 68, 3bff38) + d0
 00155660 make_jointree_rel (3bb978, 3bb770, 3bba00, 0, 0, 3c0ff0) + f0
 0014cdb8 make_fromexpr_rel (3bb978, 40ae90, 1, 0, 0, 3c0ff0) + 7c
 0014c760 make_one_rel (3bb978, 3bb978, ffbeebe8, ffbeebe0, 0, 1) + 20
 0015c2c4 subplanner (3bb978, 3c0278, 0, 0, 3c1d20, 3c1d18) + 94
 0015c1b4 query_planner (3bb978, 3bfec0, 0, 0, 4, 0) + 9c
 0015e14c grouping_planner (3bb978, bff00000, 0, 5, 0, ff1417e4) + 724
 0015c8d8 subquery_planner (3bb978, bff00000, 0, 2b1188, 51, 8000) + 2e4
 0015c580 planner  (3bb978, 0, 0, ffffffff, fffffff8, ffbeffcd) + 54
 001a50e8 pg_plan_query (3bb978, 1, 0, ffffffff, fffffff8, ffbeffcd) +
54
 001a5780 pg_exec_query_string (3bad30, 2, 3812a0, 2b8a2c, 73, 3bad48) +
5f8
 001a7634 PostgresMain (4, ffbef218, 348b91, ffbef218, 2b2c00, ffbef110)
+ 1494
 00171130 DoBackend (348a60, 1, 0, ffffffff, 21a54, 170550) + 86c
 0017055c BackendStartup (348a60, 2e27c4, 4, 4, 215d0, 16e8b0) + a8
 0016e9ac ServerLoop (60a0, 2e27e4, 2e2400, ff1bea00, ff1b801c,
ff1bea00) + 384
 0016e218 PostmasterMain (2, 322e38, 2ae400, 65720000, 74657200, 0) +
bdc
 00127ef0 main     (2, ffbefccc, ffbefcd8, 2e9d88, 0, 0) + 2e4
 00032da8 _start   (0, 0, 0, 0, 0, 0) + 5c



-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Sunday, June 29, 2003 3:25 PM
To: Maksim Likharev
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] PG crash on simple query


"Maksim Likharev" <mlikharev@aurigin.com> writes:
> LOG:  server process (pid 2004) was terminated by signal 11

> Is there any way to see what really happened?

I would like to see a stack backtrace (get a core dump, use gdb
on it.  See the archives for descriptions of the standard procedure...)

            regards, tom lane

Re: PG crash on simple query, story continues

From
Tom Lane
Date:
"Maksim Likharev" <mlikharev@aurigin.com> writes:
> SELECT p.docid FROM prod.t_documents AS p
>  INNER JOIN t_tempdocs AS t
>      ON p.docid = t.docid
>          LEFT OUTER JOIN prod.t_refs AS ct
>              ON ct.docid = p.docid;

> here is a stack trace:
>  00252174 AllocSetAlloc (3813b0, 15, 251fe0, 20, 0, ffbee2f8) + 194
>  002532e4 MemoryContextAlloc (3813b0, 15, 11, 7efefeff, 81010100, ff00)
> + 68
>  0020dc0c varcharin (ffbee378, ffbee378, 20dae4, 0, 0, ffbee3f0) + 128
>  00243570 FunctionCall3 (ffbee4a8, 3c1ce8, 0, 324, 0, ffbee5c4) + 11c
>  0023e6c4 get_attstatsslot (3d6410, 413, 324, 2, 0, ffbee5c4) + 2b0
>  001f8cb4 scalarineqsel (3bb978, 42a, 0, 3bffa8, 40f0e8, 413) + 288
>  001fb824 mergejoinscansel (3bb978, 3c0080, 3c0968, 3c0970, 0, 1) + 23c

Hmm, it would seem there's something flaky about your pg_statistic
entries.  Could we see the pg_stats rows for the columns mentioned
in this query?

            regards, tom lane