To: "John Smith" <sodgodofall@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Performance of aggregates over set-returning functions 
In-reply-to: <b88f0d670806091557m7be097fdyd2bafdf4b2706351@mail.gmail.com> 
References: <b88f0d670801081821r70fb10b4j4c176eed96918434@mail.gmail.com>
	<25214.1199848043@sss.pgh.pa.us>
	<b88f0d670801081933t6c7cc50ci896a94d7d9f7ec17@mail.gmail.com>
	<25822.1199850664@sss.pgh.pa.us>
	<b88f0d670806091557m7be097fdyd2bafdf4b2706351@mail.gmail.com>
Comments: In-reply-to "John Smith" <sodgodofall@gmail.com>
	message dated "Mon, 09 Jun 2008 15:57:52 -0700"
Date: Mon, 09 Jun 2008 20:17:24 -0400
Message-ID: <2322.1213057044@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"John Smith" <sodgodofall@gmail.com> writes:
> Sorry for the long delay in following up on this suggestion. The
> change Tom suggested fixed the performance problems I was seeing, but
> I never ran the full regression suite on the modified code, as
> everything in my performance tests seemed to indicate the bug was
> fixed (i.e, no errors even with --cassert-enabled). When I recently
> ran the regression suite on the "fixed" version of Postgres, the
> "misc" test suite fails with the following error message: "ERROR:
> cache lookup failed for type 2139062143". Is this a manifestation of
> the problem where certain items are being freed too early?

Yup --- something's trying to use memory that's already been freed.
The particular case is evidently a field containing a type OID.

You might be able to get a clue where the problem is by getting a gdb
stack trace back from errfinish(), but this sort of kills my optimism
that the 7.0-era problem is gone ...

			regards, tom lane