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
      033eb158
      Fix LISTEN/NOTIFY race condition reported by Laurent Birtz, by postponing · 033eb158
      Tom Lane authored
      pg_listener modifications commanded by LISTEN and UNLISTEN until the end
      of the current transaction.  This allows us to hold the ExclusiveLock on
      pg_listener until after commit, with no greater risk of deadlock than there
      was before.  Aside from fixing the race condition, this gets rid of a
      truly ugly kludge that was there before, namely having to ignore
      HeapTupleBeingUpdated failures during NOTIFY.  There is a small potential
      incompatibility, which is that if a transaction issues LISTEN or UNLISTEN
      and then looks into pg_listener before committing, it won't see any resulting
      row insertion or deletion, where before it would have.  It seems unlikely
      that anyone would be depending on that, though.
      
      This patch also disallows LISTEN and UNLISTEN inside a prepared transaction.
      That case had some pretty undesirable properties already, such as possibly
      allowing pg_listener entries to be made for PIDs no longer present, so
      disallowing it seems like a better idea than trying to maintain the behavior.
      033eb158
      History
      Fix LISTEN/NOTIFY race condition reported by Laurent Birtz, by postponing
      Tom Lane authored
      pg_listener modifications commanded by LISTEN and UNLISTEN until the end
      of the current transaction.  This allows us to hold the ExclusiveLock on
      pg_listener until after commit, with no greater risk of deadlock than there
      was before.  Aside from fixing the race condition, this gets rid of a
      truly ugly kludge that was there before, namely having to ignore
      HeapTupleBeingUpdated failures during NOTIFY.  There is a small potential
      incompatibility, which is that if a transaction issues LISTEN or UNLISTEN
      and then looks into pg_listener before committing, it won't see any resulting
      row insertion or deletion, where before it would have.  It seems unlikely
      that anyone would be depending on that, though.
      
      This patch also disallows LISTEN and UNLISTEN inside a prepared transaction.
      That case had some pretty undesirable properties already, such as possibly
      allowing pg_listener entries to be made for PIDs no longer present, so
      disallowing it seems like a better idea than trying to maintain the behavior.