Hi, I have very interesting suspicion:
See my comments !
convert_string_datum
...
!this is my case
if (!lc_collate_is_c())
{
/* Guess that transformed string is not much bigger than
original */
xfrmsize = strlen(val) + 32; /* arbitrary pad value
here... */
! I would say very interesting aproach,
! why not just
xfrmsize = strxfrm(xfrmstr, NULL, 0);
! fine
xfrmstr = (char *) palloc(xfrmsize);
!fine
xfrmlen = strxfrm(xfrmstr, val, xfrmsize);
!if error happend, xfrmlen will be (size_t)-1
if (xfrmlen >= xfrmsize) {
!yep did not make it
/* Oops, didn't make it */
pfree(xfrmstr);
!what do we allocating here? 0 byte
xfrmstr = (char *) palloc(xfrmlen + 1);
!BOOM
xfrmlen = strxfrm(xfrmstr, val, xfrmlen + 1);
}
pfree(val);
val = xfrmstr;
}
-----Original Message-----
From: Maksim Likharev
Sent: Tuesday, July 08, 2003 9:35 AM
To: 'Tom Lane'
Cc: [EMAIL PROTECTED]; '[EMAIL PROTECTED]'
Subject: RE: [GENERAL] PG crash on simple query, story continues
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:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 10:14 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues
"Maksim Likharev" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
