>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> The attached patch cures the leak for me
I see that the patch was applied. A CVS checkout from this morning
fixes the leak for me, too; the vmstat output stayed rock steady
during the run.
Thanks!
-Kevin
--
Sent via pgsql-hackers mailing list (pgs
Hah, got it. The reason the leak only manifests on 32-bit is that it
only manifests if int8 is a pass-by-reference datatype. The new API
for amgetbitmap causes a query-lifespan leak of one palloc(sizeof(int8))
per bitmap index scan. The distinguishing feature of your query seems
to be just that
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I've got the database down to the minimum database objects needed for
> the query (three tables, five views on them, and a bunch of domains),
> and gotten those tables down to 10% of their original size, with all
> confidential data turned to meaningle
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> The tables and views aren't that hard; finding a way to generate
>> enough fake data may be a challenge. (I assume that since it took
>> over a half hour to run out of memory, the volume of data needs to
be
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> Also, does the leak still occur if
> you just run the query as-is rather than EXPLAIN ANALYZE it?
The machine became unresponsive similar to the early symptoms of the
apparent memory leak cited in this post:
http://archives.postgresql.org/pgsql-bugs/
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> The tables and views aren't that hard; finding a way to generate
> enough fake data may be a challenge. (I assume that since it took
> over a half hour to run out of memory, the volume of data needs to be
> sufficient to get there.)
We don't really n
>>> Tom Lane <[EMAIL PROTECTED]> wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8
chunks);
> 1615136 used
>> ExecutorState: 2787288448 total in 364 blocks; 328 free (5
chunks);
> 2787288120 used
>
> Ouch. We have cre
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> PortalHeapMemory: 1620992 total in 200 blocks; 5856 free (8 chunks);
> 1615136 used
> ExecutorState: 2787288448 total in 364 blocks; 328 free (5 chunks);
> 2787288120 used
Ouch. We have created a memory leak someplace, but it's hard to te
I was testing a very complex statistical query, with (among other
things) many EXISTS and NOT EXISTS tests against a build of the source
snapshot from 3 September. (The query looks pretty innocent, but
those aren't tables, they're complicated views.) Under 8.3.3 this
query runs successfully, but
