Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors
Date
Msg-id 50C87730.4010707@vmware.com
Whole thread Raw
In response to Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors  (David Gould <daveg@sonic.net>)
Responses Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors  (David Gould <daveg@sonic.net>)
Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12.12.2012 14:17, David Gould wrote:
> On Wed, 12 Dec 2012 12:27:11 +0100
> Andres Freund<andres@2ndquadrant.com>  wrote:
>
>> On 2012-12-12 03:04:19 -0800, David Gould wrote:
>>>
>>> COPY IN loops in heap_multi_insert() extending the table until it fills the
>
>> Heh. Nice one. Did you hit that in practice?
>
> Yeah, with a bunch of hosts that run postgres on a ramdisk, and that copy
> happens late in the initial setup script for new hosts. The first batch of
> new hosts to be setup with 9.2 filled the ramdisk, oomed and fell over
> within a minute. Since the script setups up a lot of stuff we had no idea
> at first who oomed.

The bug's been fixed now, but note that huge tuples like this will 
always cause the table to be extended. Even if there are completely 
empty pages in the table, after a vacuum. Even a completely empty 
existing page is not considered spacious enough in this case, because 
it's still too small when you take fillfactor into account, so the 
insertion will always extend the table. If you regularly run into this 
situation, you might want to raise your fillfactor..

- Heikki



pgsql-hackers by date:

Previous
From: David Gould
Date:
Subject: Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors
Next
From: David Gould
Date:
Subject: Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors