After upgrade on 7.3.3 we have following:
signal 11
#0 0x254f38 in pfree ()
#1 0x1fde44 in convert_to_scalar ()
#2 0x1faafc in scalarineqsel ()
#3 0x1fd574 in mergejoinscansel ()
#4 0x14fec8 in cost_mergejoin ()
#5 0x16b820 in create_mergejoin_path ()
#6 0x155048 in sort_inner_and_outer ()
#7 0x154dd0 in add_paths_to_joinrel ()
#8 0x1567cc in make_join_rel ()
#9 0x15669c in make_jointree_rel ()
#10 0x14dd28 in make_fromexpr_rel ()
#11 0x14d6d0 in make_one_rel ()
#12 0x15d328 in subplanner ()
#13 0x15d218 in query_planner ()
#14 0x15f29c in grouping_planner ()
#15 0x15d93c in subquery_planner ()
#16 0x15d5e4 in planner ()
#17 0x1a6a94 in pg_plan_query ()
#18 0x1a712c in pg_exec_query_string ()
#19 0x1a8fd8 in PostgresMain ()
#20 0x172698 in DoBackend ()
#21 0x171ac4 in BackendStartup ()
#22 0x16ff14 in ServerLoop ()
#23 0x16f780 in PostmasterMain ()
#24 0x128e60 in main ()
-----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
