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
> disk when trying to insert a wide row into a table with a low fill-factor.
> Internally fill-factor is implemented by reserving some space space on a
> page. For large enough rows and small enough fill-factor bulk_multi_insert()
> can't fit the row even on a new empty page, so it keeps allocating new pages
> but is never able to place the row. It should always put at least one row on
> an empty page.
Heh. Nice one. Did you hit that in practice?
> One more point, in the case where we don't insert any rows, we still do all
> the
> dirtying and logging work even though we did not modify the page. I have tried
> skip all this if no rows are added (nthispage == 0), but my access method foo
> is sadly out of date, so someone should take a skeptical look at that.
>
> A test case and patch against 9.2.2 is attached. It fixes the problem and
> passes
> make check. Most of the diff is just indentation changes. Whoever tries this
> will
> want to test this on a small partition by itself.
ISTM this would be fixed with a smaller footprint by just making
if (PageGetHeapFreeSpace(page) < MAXALIGN(heaptup->t_len) + saveFreeSpace)
if (!PageIsEmpty(page) &&
PageGetHeapFreeSpace(page) < MAXALIGN(heaptup->t_len) + saveFreeSpace)
I think that should work?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
