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

tablespace.c

Blame
    • Tom Lane's avatar
      5fc78efc
      Avoid throwing ERROR during WAL replay of DROP TABLESPACE. · 5fc78efc
      Tom Lane authored
      Although we will not even issue an XLOG_TBLSPC_DROP WAL record unless
      removal of the tablespace's directories succeeds, that does not guarantee
      that the same operation will succeed during WAL replay.  Foreseeable
      reasons for it to fail include temp files created in the tablespace by Hot
      Standby backends, wrong directory permissions on a standby server, etc etc.
      The original coding threw ERROR if replay failed to remove the directories,
      but that is a serious overreaction.  Throwing an error aborts recovery,
      and worse means that manual intervention will be needed to get the database
      to start again, since otherwise the same error will recur on subsequent
      attempts to replay the same WAL record.  And the consequence of failing to
      remove the directories is only that some probably-small amount of disk
      space is wasted, so it hardly seems justified to throw an error.
      Accordingly, arrange to report such failures as LOG messages and keep going
      when a failure occurs during replay.
      
      Back-patch to 9.0 where Hot Standby was introduced.  In principle such
      problems can occur in earlier releases, but Hot Standby increases the odds
      of trouble significantly.  Given the lack of field reports of such issues,
      I'm satisfied with patching back as far as the patch applies easily.
      5fc78efc
      History
      Avoid throwing ERROR during WAL replay of DROP TABLESPACE.
      Tom Lane authored
      Although we will not even issue an XLOG_TBLSPC_DROP WAL record unless
      removal of the tablespace's directories succeeds, that does not guarantee
      that the same operation will succeed during WAL replay.  Foreseeable
      reasons for it to fail include temp files created in the tablespace by Hot
      Standby backends, wrong directory permissions on a standby server, etc etc.
      The original coding threw ERROR if replay failed to remove the directories,
      but that is a serious overreaction.  Throwing an error aborts recovery,
      and worse means that manual intervention will be needed to get the database
      to start again, since otherwise the same error will recur on subsequent
      attempts to replay the same WAL record.  And the consequence of failing to
      remove the directories is only that some probably-small amount of disk
      space is wasted, so it hardly seems justified to throw an error.
      Accordingly, arrange to report such failures as LOG messages and keep going
      when a failure occurs during replay.
      
      Back-patch to 9.0 where Hot Standby was introduced.  In principle such
      problems can occur in earlier releases, but Hot Standby increases the odds
      of trouble significantly.  Given the lack of field reports of such issues,
      I'm satisfied with patching back as far as the patch applies easily.