Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] contrib module intagg crashing the backend

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>,pgsql-general(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [GENERAL] contrib module intagg crashing the backend
Date: 2005-03-23 18:36:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-general
I wrote:
> Grumble ... I seem to have managed to promote intagg from
> broken-on-64bit-platforms to broken-on-every-platform ...
> will look into a fix tomorrow.

Ron's problem is essentially a double-free bug.  In this patch:

2005-01-27 16:35  tgl

	* contrib/intagg/: int_aggregate.c,
	(REL7_3_STABLE), int_aggregate.c,
	(REL7_4_STABLE), int_aggregate.c,
	(REL8_0_STABLE), int_aggregate.c, Fix
	security and 64-bit issues in contrib/intagg.  This code could
	stand to be rewritten altogether, but for now just stick a finger
	in the dike.

I modified intagg to declare its transition data type as int4[] (which
is what it really is) rather than int4.  Unfortunately that means that
nodeAgg.c is now aware that the transition value is pass-by-reference,
and so it thinks it needs to manage the memory used for it; which
intagg.c is also trying to do; so they both free the same bit of memory.

There is already a "proper" fix for this problem in CVS tip, but it's
too invasive to consider back-patching; not least because nodeAgg's
memory management strategy has changed since 7.3 and the fix would
probably not work that far back.

What I'm thinking I have to do is revert intagg in the back branches to
lie about its transition data type, but still have it pull the pointer
out of the passed Datum with DatumGetPointer (as opposed to the old,
definitely 64-bit-broken method of DatumGetInt32 and then cast to pointer).
This should work because nodeAgg doesn't inquire into the actual
contents of any Datum it doesn't think is pass-by-reference; so it will
never discard the upper bits of the pointer.

Ugh.  Glad we have a cleaner solution to go forward with.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Keith BrowneDate: 2005-03-23 19:22:07
Subject: Re: BUG #1552: massive performance hit between 7.4 and 8.0.1
Previous:From: Sergio LobDate: 2005-03-23 18:32:54
Subject: Precision and scale of numeric column reported as value -1

pgsql-general by date

Next:From: AndrusDate: 2005-03-23 18:47:36
Subject: Re: Using sequence name depending on other column
Previous:From: Tom LaneDate: 2005-03-23 18:11:18
Subject: Re: Simple query takes a long time on win2K

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group