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

freespace.c

Blame
    • Heikki Linnakangas's avatar
      917dc7d2
      Fix WAL-logging of FSM and VM truncation. · 917dc7d2
      Heikki Linnakangas authored
      When a relation is truncated, it is important that the FSM is truncated as
      well. Otherwise, after recovery, the FSM can return a page that has been
      truncated away, leading to errors like:
      
      ERROR:  could not read block 28991 in file "base/16390/572026": read only 0
      of 8192 bytes
      
      We were using MarkBufferDirtyHint() to dirty the buffer holding the last
      remaining page of the FSM, but during recovery, that might in fact not
      dirty the page, and the FSM update might be lost.
      
      To fix, use the stronger MarkBufferDirty() function. MarkBufferDirty()
      requires us to do WAL-logging ourselves, to protect from a torn page, if
      checksumming is enabled.
      
      Also fix an oversight in visibilitymap_truncate: it also needs to WAL-log
      when checksumming is enabled.
      
      Analysis by Pavan Deolasee.
      
      Discussion: <CABOikdNr5vKucqyZH9s1Mh0XebLs_jRhKv6eJfNnD2wxTn=_9A@mail.gmail.com>
      917dc7d2
      History
      Fix WAL-logging of FSM and VM truncation.
      Heikki Linnakangas authored
      When a relation is truncated, it is important that the FSM is truncated as
      well. Otherwise, after recovery, the FSM can return a page that has been
      truncated away, leading to errors like:
      
      ERROR:  could not read block 28991 in file "base/16390/572026": read only 0
      of 8192 bytes
      
      We were using MarkBufferDirtyHint() to dirty the buffer holding the last
      remaining page of the FSM, but during recovery, that might in fact not
      dirty the page, and the FSM update might be lost.
      
      To fix, use the stronger MarkBufferDirty() function. MarkBufferDirty()
      requires us to do WAL-logging ourselves, to protect from a torn page, if
      checksumming is enabled.
      
      Also fix an oversight in visibilitymap_truncate: it also needs to WAL-log
      when checksumming is enabled.
      
      Analysis by Pavan Deolasee.
      
      Discussion: <CABOikdNr5vKucqyZH9s1Mh0XebLs_jRhKv6eJfNnD2wxTn=_9A@mail.gmail.com>