Re: Re: bulk_multi_insert infinite loops with large rows and small fill factors
Heikki Linnakangas <hlinnakangas@vmware.com>
From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: David Gould <daveg@sonic.net>
Cc: Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Anand Ranganathan <arangana@adobe.com>, Alex Eulenberg <aeulenbe@adobe.com>, Ashokraj M <ashokraj@adobe.com>, Hari <hari@adobe.com>, Elein Mustain <mustain@adobe.com>
Date: 2012-12-12T12:23:12Z
Lists: 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