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

async.c

Blame
    • Tom Lane's avatar
      53e95eee
      Fix for rare race-condition-like failure: if a backend receives SIGUSR2 · 53e95eee
      Tom Lane authored 
      (notify/SI-overrun interrupt) while it is in process of doing proc_exit,
it is possible for Async_NotifyHandler() to try to start a transaction
when one is already running.  This leads to Asserts() or worse.  I think
it may only be possible to occur when frontend synchronization is lost
(ie, the elog(FATAL) in SocketBackend() fires), but that is a standard
occurrence after error during COPY.  In any case, I have seen this
failure occur during regression tests, so it is definitely possible.
      53e95eee
      History
      Fix for rare race-condition-like failure: if a backend receives SIGUSR2
      Tom Lane authored 
      (notify/SI-overrun interrupt) while it is in process of doing proc_exit,
it is possible for Async_NotifyHandler() to try to start a transaction
when one is already running.  This leads to Asserts() or worse.  I think
it may only be possible to occur when frontend synchronization is lost
(ie, the elog(FATAL) in SocketBackend() fires), but that is a standard
occurrence after error during COPY.  In any case, I have seen this
failure occur during regression tests, so it is definitely possible.