Re: PG crash on simple query, story continues

Started by Maksim Likharevalmost 23 years ago4 messagesgeneral

mlikharev@aurigin.com

almost 23 years ago

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

Tom Lane

tgl@sss.pgh.pa.us

almost 23 years ago

In reply to: Maksim Likharev (#1)

"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

Maksim Likharev

mlikharev@aurigin.com

almost 23 years ago

In reply to: Tom Lane (#2)

What should I select?

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, July 07, 2003 10:14 PM
To: Maksim Likharev
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] PG crash on simple query, story continues

"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

Import Notes

Resolved by subject fallback

Maksim Likharev

mlikharev@aurigin.com

almost 23 years ago

In reply to: Maksim Likharev (#3)

I do not know whether this what you are looking for:

select * from pg_stats where tablename = 't_refs';
schemaname | tablename | attname | null_frac | avg_width |
n_distinct | most_common_vals | most_common_freqs |
histogram_bounds
| correlation
------------+-------------+----------+-----------+-----------+----------
--+--------------------+-------------------+----------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------+-------------
prod | t_refs | refid | 0 | 4 | -0.103007 |
{3015397} | {0.000666667} |
{653,2471487,2979200,3413832,5264245,6331043,6937529,7784921,8629416,189
45386,22438228}
| 0.999997
prod | t_refs | docid | 0 | 20 | -0.103007 |
{UU000005835738A_} | {0.000666667} |
{DD000002138111A1,PP000000392895A2,JJ001996061410A_,UU000002979269A_,UU0
00003695300A_,UU000004114255A_,UU000004488542A_,UU000004843496A_,UU00000
5258342A_,UU000005754178A_,WW002001026472A1} | -0.226872

select * from pg_stats where tablename = 't_documents';
bib=# select * from pg_stats where tablename = 't_documents';
schemaname | tablename | attname | null_frac | avg_width |
n_distinct |
most_common_vals |
most_common_freqs |
histogram_bounds
| correlation
------------+-----------+----------------------+-----------+-----------+
------------+-----------------------------------------------------------
------------------------------------------------------+-----------------
------------------------------------------------------------------------
------------------------+-----------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
-----------------------------+--------------
prod | t_documents | documentid | 0 | 4
| -1 |
|
|
{4412,2108436,4019706,6197781,8156754,9979302,14177441,16191587,18253432
,20472500,22408280}
| 0.444682
prod | t_documents | docid | 0 | 20
| -1 |
|
|
{DD000000336233T1,PP000000284550A1,GB000000613469A_,JJ001984091431A_,JJ0
01992265537A_,JJ001998164783A_,UU000000488247A_,UU000002597243A_,UU00000
4506762A_,UU000006365747B1,WW002003043835A1}
| 0.168566

"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

Import Notes

Resolved by subject fallback