forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit77a1ba2
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 askfor a new page from RelationGetBufferForTuple. If a tuple is too large tofit on any page, taking fillfactor into account, RelationGetBufferForTuplewill always expand the relation. In a normal insert, heap_insert will acceptthat and put the tuple on the new page. heap_multi_insert, however, does afillfactor check of its own, and doesn't accept the newly-extended pageRelationGetBufferForTuple returns, even though there is no other choice tomake the tuple fit.Fix that by making the logic in heap_multi_insert more like the heap_insertlogic. The first tuple is always put on the page RelationGetBufferForTuplegives us, and the fillfactor check is only applied to the subsequent tuples.Report from David Gould, although I didn't use his patch.1 parent8bb937c commit77a1ba2
1 file changed
+6
-2
lines changedLines changed: 6 additions & 2 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
2172 | 2172 |
| |
2173 | 2173 |
| |
2174 | 2174 |
| |
2175 |
| - | |
2176 |
| - | |
| 2175 | + | |
| 2176 | + | |
| 2177 | + | |
| 2178 | + | |
| 2179 | + | |
| 2180 | + | |
2177 | 2181 |
| |
2178 | 2182 |
| |
2179 | 2183 |
| |
|
0 commit comments
Comments
(0)