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

bufmgr.h

Blame
    • Tom Lane's avatar
      061b079f
      Fix multiple bugs in index page locking during hot-standby WAL replay. · 061b079f
      Tom Lane authored
      In ordinary operation, VACUUM must be careful to take a cleanup lock on
      each leaf page of a btree index; this ensures that no indexscans could
      still be "in flight" to heap tuples due to be deleted.  (Because of
      possible index-tuple motion due to concurrent page splits, it's not enough
      to lock only the pages we're deleting index tuples from.)  In Hot Standby,
      the WAL replay process must likewise lock every leaf page.  There were
      several bugs in the code for that:
      
      * The replay scan might come across unused, all-zero pages in the index.
      While btree_xlog_vacuum itself did the right thing (ie, nothing) with
      such pages, xlogutils.c supposed that such pages must be corrupt and
      would throw an error.  This accounts for various reports of replication
      failures with "PANIC: WAL contains references to invalid pages".  To
      fix, add a ReadBufferMode value that instructs XLogReadBufferExtended
      not to complain when we're doing this.
      
      * btree_xlog_vacuum performed the extra locking if standbyState ==
      STANDBY_SNAPSHOT_READY, but that's not the correct test: we won't open up
      for hot standby queries until the database has reached consistency, and
      we don't want to do the extra locking till then either, for fear of reading
      corrupted pages (which bufmgr.c would complain about).  Fix by exporting a
      new function from xlog.c that will report whether we're actually in hot
      standby replay mode.
      
      * To ensure full coverage of the index in the replay scan, btvacuumscan
      would emit a dummy WAL record for the last page of the index, if no
      vacuuming work had been done on that page.  However, if the last page
      of the index is all-zero, that would result in corruption of said page,
      since the functions called on it weren't prepared to handle that case.
      There's no need to lock any such pages, so change the logic to target
      the last normal leaf page instead.
      
      The first two of these bugs were diagnosed by Andres Freund, the other one
      by me.  Fixes based on ideas from Heikki Linnakangas and myself.
      
      This has been wrong since Hot Standby was introduced, so back-patch to 9.0.
      061b079f
      History
      Fix multiple bugs in index page locking during hot-standby WAL replay.
      Tom Lane authored
      In ordinary operation, VACUUM must be careful to take a cleanup lock on
      each leaf page of a btree index; this ensures that no indexscans could
      still be "in flight" to heap tuples due to be deleted.  (Because of
      possible index-tuple motion due to concurrent page splits, it's not enough
      to lock only the pages we're deleting index tuples from.)  In Hot Standby,
      the WAL replay process must likewise lock every leaf page.  There were
      several bugs in the code for that:
      
      * The replay scan might come across unused, all-zero pages in the index.
      While btree_xlog_vacuum itself did the right thing (ie, nothing) with
      such pages, xlogutils.c supposed that such pages must be corrupt and
      would throw an error.  This accounts for various reports of replication
      failures with "PANIC: WAL contains references to invalid pages".  To
      fix, add a ReadBufferMode value that instructs XLogReadBufferExtended
      not to complain when we're doing this.
      
      * btree_xlog_vacuum performed the extra locking if standbyState ==
      STANDBY_SNAPSHOT_READY, but that's not the correct test: we won't open up
      for hot standby queries until the database has reached consistency, and
      we don't want to do the extra locking till then either, for fear of reading
      corrupted pages (which bufmgr.c would complain about).  Fix by exporting a
      new function from xlog.c that will report whether we're actually in hot
      standby replay mode.
      
      * To ensure full coverage of the index in the replay scan, btvacuumscan
      would emit a dummy WAL record for the last page of the index, if no
      vacuuming work had been done on that page.  However, if the last page
      of the index is all-zero, that would result in corruption of said page,
      since the functions called on it weren't prepared to handle that case.
      There's no need to lock any such pages, so change the logic to target
      the last normal leaf page instead.
      
      The first two of these bugs were diagnosed by Andres Freund, the other one
      by me.  Fixes based on ideas from Heikki Linnakangas and myself.
      
      This has been wrong since Hot Standby was introduced, so back-patch to 9.0.