Re: bulk_multi_insert infinite loops with large rows and small fill factors

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