Skip to content

Commit 77a1ba2

Browse files
committed
In multi-insert, don't go into infinite loop on a huge tuple and fillfactor.
If a tuple is larger than page size minus space reserved for fillfactor, heap_multi_insert would never find a page that it fits in and repeatedly ask for a new page from RelationGetBufferForTuple. If a tuple is too large to fit on any page, taking fillfactor into account, RelationGetBufferForTuple will always expand the relation. In a normal insert, heap_insert will accept that and put the tuple on the new page. heap_multi_insert, however, does a fillfactor check of its own, and doesn't accept the newly-extended page RelationGetBufferForTuple returns, even though there is no other choice to make the tuple fit. Fix that by making the logic in heap_multi_insert more like the heap_insert logic. The first tuple is always put on the page RelationGetBufferForTuple gives us, and the fillfactor check is only applied to the subsequent tuples. Report from David Gould, although I didn't use his patch.
1 parent 8bb937c commit 77a1ba2

File tree

1 file changed

+6
-2
lines changed

1 file changed

+6
-2
lines changed

src/backend/access/heap/heapam.c

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2172,8 +2172,12 @@ heap_multi_insert(Relation relation, HeapTuple *tuples, int ntuples,
21722172
/* NO EREPORT(ERROR) from here till changes are logged */
21732173
START_CRIT_SECTION();
21742174

2175-
/* Put as many tuples as fit on this page */
2176-
for (nthispage = 0; ndone + nthispage < ntuples; nthispage++)
2175+
/*
2176+
* RelationGetBufferForTuple has ensured that the first tuple fits.
2177+
* Put that on the page, and then as many other tuples as fit.
2178+
*/
2179+
RelationPutHeapTuple(relation, buffer, heaptuples[ndone]);
2180+
for (nthispage = 1; ndone + nthispage < ntuples; nthispage++)
21772181
{
21782182
HeapTuple heaptup = heaptuples[ndone + nthispage];
21792183

0 commit comments

Comments
 (0)