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

receivelog.c

Blame
    • Fujii Masao's avatar
      f66c20b3
      Fix pg_receivexlog --slot so that it doesn't prevent the server shutdown. · f66c20b3
      Fujii Masao authored
      When pg_receivexlog --slot is connecting to the server, at the shutdown
      of the server, walsender keeps waiting for the last WAL record to be
      replicated and flushed in pg_receivexlog. But previously pg_receivexlog
      issued sync command only when WAL file was switched. So there was
      the case where the last WAL was never flushed and walsender had to
      keep waiting infinitely. This caused the server shutdown to get stuck.
      
      pg_recvlogical handles this problem by calling fsync() when it receives
      the request of immediate reply from the server. That is, at shutdown,
      walsender sends the request, pg_recvlogical receives it, flushes the last
      WAL record, and sends the flush location back to the server. Since
      walsender can see that the last WAL record is successfully flushed, it can
      exit cleanly.
      
      This commit introduces the same logic as pg_recvlogical has,
      to pg_receivexlog.
      
      Back-patch to 9.4 where pg_receivexlog was changed so that it can use
      the replication slot.
      
      Original patch by Michael Paquier, rewritten by me.
      Bug report by Furuya Osamu.
      f66c20b3
      History
      Fix pg_receivexlog --slot so that it doesn't prevent the server shutdown.
      Fujii Masao authored
      When pg_receivexlog --slot is connecting to the server, at the shutdown
      of the server, walsender keeps waiting for the last WAL record to be
      replicated and flushed in pg_receivexlog. But previously pg_receivexlog
      issued sync command only when WAL file was switched. So there was
      the case where the last WAL was never flushed and walsender had to
      keep waiting infinitely. This caused the server shutdown to get stuck.
      
      pg_recvlogical handles this problem by calling fsync() when it receives
      the request of immediate reply from the server. That is, at shutdown,
      walsender sends the request, pg_recvlogical receives it, flushes the last
      WAL record, and sends the flush location back to the server. Since
      walsender can see that the last WAL record is successfully flushed, it can
      exit cleanly.
      
      This commit introduces the same logic as pg_recvlogical has,
      to pg_receivexlog.
      
      Back-patch to 9.4 where pg_receivexlog was changed so that it can use
      the replication slot.
      
      Original patch by Michael Paquier, rewritten by me.
      Bug report by Furuya Osamu.