Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgres-lambda-diff

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Heikki Linnakangas authored
    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.
    6264cd3d
    History
    Name Last commit Last update