Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id EE13919CDE12
	for <pgsql-novice@postgresql.org>; Mon,  5 Dec 2011 12:24:14 -0400 (AST)
Received: from zeus.simkin.ca ([72.51.27.124])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <ahodgson@simkin.ca>) id 1RXbKt-0001Ka-Tm
	for pgsql-novice@postgresql.org; Mon, 05 Dec 2011 16:24:14 +0000
Received: from skynet.simkin.ca (vpn.reinvent.com [72.51.27.50])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by zeus.simkin.ca (Postfix) with ESMTPSA id 9B00D27090F
	for <pgsql-novice@postgresql.org>; Mon,  5 Dec 2011 08:23:57 -0800 (PST)
From: Alan Hodgson <ahodgson@simkin.ca>
To: pgsql-novice@postgresql.org
Subject: Re: Linux server connection process consumes all memory
Date: Mon, 5 Dec 2011 08:23:55 -0800
User-Agent: KMail/1.13.7 (Linux/3.0.6-gentoo; KDE/4.6.5; x86_64; ; )
References: <B56C2BFC6806BE4A9C86ADDDD269933A6E8A09@appserver.anatec.local>
	<23418.1323016204@sss.pgh.pa.us> <4EDC9FE0.8030506@anatec.com>
In-Reply-To: <4EDC9FE0.8030506@anatec.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201112050823.55438.ahodgson@simkin.ca>
X-Pg-Spam-Score: -3.1 (---)
X-Archive-Number: 201112/20
X-Sequence-Number: 25786

On Monday, December 05, 2011 02:41:36 AM Ioannis Anagnostopoulos wrote:
> The top below show the "updated" query running. This time the load is at
> 8.9% right at the end of the run. Nowhere near the 96% but please
> keep in mind that this happened when I reduced to iterations to 55.000.
> 

Reduce it to 3 or 4. Turn on statement logging per Tom's request. Empty the 
logs. Restart PostgreSQL. Do one run. Let's see everything PostgreSQL is 
actually getting from the client.

Also ... please don't top-post.

> On 04/12/2011 16:30, Tom Lane wrote:
> > 
> > I don't know much of anything about VB, but I am filled with suspicion
> > that something in the VB infrastructure you're using is not doing what
> > you think.  In particular, I'm betting that repeated executions of this
> > code are in fact generating new prepared statements without deallocating
> > old ones.  You could investigate that theory by setting log_statement =
> > all in the server configuration and then watching the server log to see
> > exactly what SQL commands are actually getting sent.
> > 
> > 			regards, tom lane