diff options
author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2012-12-12 13:34:03 +0200 |
---|---|---|
committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2012-12-12 13:46:39 +0200 |
commit | 77a1ba20aa7b7caae4396e2afa5d86132fd36f6b (patch) | |
tree | aacd9805a0843b06c3192b24aa4e09e1ebeafa38 /src/backend/utils/adt/dbsize.c | |
parent | 8bb937cc53a4568388c5ae85386eed58d88e5853 (diff) | |
download | postgresql-77a1ba20aa7b7caae4396e2afa5d86132fd36f6b.tar.gz postgresql-77a1ba20aa7b7caae4396e2afa5d86132fd36f6b.zip |
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.
Diffstat (limited to 'src/backend/utils/adt/dbsize.c')
0 files changed, 0 insertions, 0 deletions