In-Reply-To: <14610.1114285856@sss.pgh.pa.us>
References: <6f4567d4e64297b356e2d71ec392cdae@richardplotkin.com>
	<4574.1114030270@sss.pgh.pa.us>
	<9c5b2bf6a0f5a0bc0abeb6b6c5cf7973@richardplotkin.com>
	<2a9467bc6e6dab5d997427c4ef6158e3@richardplotkin.com>
	<12016.1114279585@sss.pgh.pa.us>
	<c4a45adf8fdcb550f487a1ca7f9cfff5@richardplotkin.com>
	<12135.1114280225@sss.pgh.pa.us>
	<31935aa56e9539c5648cb09e78152c03@richardplotkin.com>
	<14610.1114285856@sss.pgh.pa.us>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <2dc4db3fb0cb69c0dec1440acd5c1ceb@richardplotkin.com>
Content-Transfer-Encoding: 7bit
Cc: pgsql-performance@postgresql.org
From: Richard Plotkin <richard@richardplotkin.com>
Subject: Re: Disk filling, CPU filling, renegade inserts and deletes? 
Date: Sun, 24 Apr 2005 20:13:47 -0700
To: Tom Lane <tgl@sss.pgh.pa.us>

Hi Tom,

Thanks!  That's exactly what it was.  There was a discrepancy in the 
data that turned this into an endless loop.  Everything has been 
running smoothly since I made a change.

Thanks so much,
Richard

On Apr 23, 2005, at 12:50 PM, Tom Lane wrote:

> Richard Plotkin <richard@richardplotkin.com> writes:
>> Thanks for your responses this morning.  I did the select relname, and
>> it returned 0 rows.  I do have one function that creates a temp table
>> and fills it within the same transaction.  I'm pasting it below.
>> Perhaps the "ON COMMIT DROP" is causing problems, and I need to drop
>> the table at the end of the function instead of using ON COMMIT DROP?
>
> Well, I think we can conclude that the function is pushing way more
> data into the temp table than you expect.  I am wondering if that loop
> in the middle of the function is turning into an infinite loop --- 
> could
> it be finding some sort of cycle in your page data?  You might want to
> add some RAISE NOTICE commands to the loop so you can track what it's
> doing.
>
> 			regards, tom lane
>