aboutsummaryrefslogtreecommitdiff
path: root/src/bin/psql/stringutils.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2012-12-12 13:34:03 +0200
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2012-12-12 13:54:42 +0200
commit6264cd3d69b519b6e6f2470e3c23ad1ef1ddff66 (patch)
tree2ebebf7056ae61e2dac27e42d58cd0c01ecb8df5 /src/bin/psql/stringutils.c
parent691c5ebf79bb011648fad0e6b234b94a28177e3c (diff)
downloadpostgresql-6264cd3d69b519b6e6f2470e3c23ad1ef1ddff66.tar.gz
postgresql-6264cd3d69b519b6e6f2470e3c23ad1ef1ddff66.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/bin/psql/stringutils.c')
0 files changed, 0 insertions, 0 deletions