From: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: In multi-insert, don't go into infinite loop on a huge tuple and |
Date: | 2012-12-12 11:55:33 |
Message-ID: | E1TikuT-0007Zj-2B@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/6264cd3d69b519b6e6f2470e3c23ad1ef1ddff66
Modified Files
--------------
src/backend/access/heap/heapam.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-12-13 13:05:56 | pgsql: Make xlog_internal.h includable in frontend context. |
Previous Message | Tom Lane | 2012-12-12 03:10:17 | pgsql: Add defenses against integer overflow in dynahash numbuckets cal |