To: Vincent Dautremont <vincent@searidgetech.com>
cc: pgsql-admin@postgresql.org
Subject: Re: out of memory error 
In-reply-to: 
 <CAA4Vp4_pD3tc8dT8rtdPjO4vQfW+eyuNpYb72HPYYRokdPHS7A@mail.gmail.com>
References: 
 <CAA4Vp4_pD3tc8dT8rtdPjO4vQfW+eyuNpYb72HPYYRokdPHS7A@mail.gmail.com>
Comments: In-reply-to Vincent Dautremont <vincent@searidgetech.com>
	message dated "Tue, 22 May 2012 12:44:41 -0400"
Date: Tue, 22 May 2012 13:33:43 -0400
Message-ID: <3902.1337708023@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vincent Dautremont <vincent@searidgetech.com> writes:
>  after a few days, i'm seeing the following logs in a database (postgresql
> 8.3.15 on Windows)
> running with rubyrep 1.2.0 for syncing a few table small that have frequent
> update / insert/ delete.
> I don't understand it and I'd like to know what happens and why. How to get
> rid of it.

Well, this is a bit unusual:

> TopMemoryContext: 197681816 total in 24131 blocks; 394104 free (24179
> chunks); 197287712 used

It's not normal to have so much stuff in TopMemoryContext.  That could
represent a leak, but it's also possible that that's just management
overhead for all of these contexts:

>     SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
>     CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
>     CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
>     SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used

> .
> .
> . there it goes for about 80MB of log then it ends
> .
> .
>  SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
>     CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
>     CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used

That's a *heck* of a lot of SPI plans.  You haven't provided any
information that would let anybody diagnose why you have so many,
though.  Tell us about your usage patterns, especially of PL-language
functions.

			regards, tom lane