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

walreceiverfuncs.c

Blame
    • Heikki Linnakangas's avatar
      2ffa66f4
      Fix walsender failure at promotion. · 2ffa66f4
      Heikki Linnakangas authored
      If a standby server has a cascading standby server connected to it, it's
      possible that WAL has already been sent up to the next WAL page boundary,
      splitting a WAL record in the middle, when the first standby server is
      promoted. Don't throw an assertion failure or error in walsender if that
      happens.
      
      Also, fix a variant of the same bug in pg_receivexlog: if it had already
      received WAL on previous timeline up to a segment boundary, when the
      upstream standby server is promoted so that the timeline switch record falls
      on the previous segment, pg_receivexlog would miss the segment containing
      the timeline switch. To fix that, have walsender send the position of the
      timeline switch at end-of-streaming, in addition to the next timeline's ID.
      It was previously assumed that the switch happened exactly where the
      streaming stopped.
      
      Note: this is an incompatible change in the streaming protocol. You might
      get an error if you try to stream over timeline switches, if the client is
      running 9.3beta1 and the server is more recent. It should be fine after a
      reconnect, however.
      
      Reported by Fujii Masao.
      2ffa66f4
      History
      Fix walsender failure at promotion.
      Heikki Linnakangas authored
      If a standby server has a cascading standby server connected to it, it's
      possible that WAL has already been sent up to the next WAL page boundary,
      splitting a WAL record in the middle, when the first standby server is
      promoted. Don't throw an assertion failure or error in walsender if that
      happens.
      
      Also, fix a variant of the same bug in pg_receivexlog: if it had already
      received WAL on previous timeline up to a segment boundary, when the
      upstream standby server is promoted so that the timeline switch record falls
      on the previous segment, pg_receivexlog would miss the segment containing
      the timeline switch. To fix that, have walsender send the position of the
      timeline switch at end-of-streaming, in addition to the next timeline's ID.
      It was previously assumed that the switch happened exactly where the
      streaming stopped.
      
      Note: this is an incompatible change in the streaming protocol. You might
      get an error if you try to stream over timeline switches, if the client is
      running 9.3beta1 and the server is more recent. It should be fine after a
      reconnect, however.
      
      Reported by Fujii Masao.