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

nbtsearch.c

Blame
    • Amit Kapila's avatar
      09a5be58
      Fix the buffer release order for parallel index scans. · 09a5be58
      Amit Kapila authored
      During parallel index scans, if the current page to be read is deleted, we
      skip it and try to get the next page for a scan without releasing the buffer
      lock on the current page.  To get the next page, sometimes it needs to wait
      for another process to complete its scan and advance it to the next page.
      Now, it is quite possible that the master backend has errored out before
      advancing the scan and issued a termination signal for all workers.  The
      workers failed to notice the termination request during wait because the
      interrupts are held due to buffer lock on the previous page.  This lead to
      all workers being stuck.
      
      The fix is to release the buffer lock on current page before trying to get
      the next page.  We are already doing same in backward scans, but missed
      it for forward scans.
      
      Reported-by: Victor Yegorov
      Bug: 15290
      Diagnosed-by: Thomas Munro and Amit Kapila
      Author: Amit Kapila
      Reviewed-by: Thomas Munro
      Tested-By: Thomas Munro and Victor Yegorov
      Backpatch-through: 10 where parallel index scans were introduced
      Discussion:https://postgr.es/m/153228422922.1395.1746424054206154747@wrigleys.postgresql.org
      09a5be58
      History
      Fix the buffer release order for parallel index scans.
      Amit Kapila authored
      During parallel index scans, if the current page to be read is deleted, we
      skip it and try to get the next page for a scan without releasing the buffer
      lock on the current page.  To get the next page, sometimes it needs to wait
      for another process to complete its scan and advance it to the next page.
      Now, it is quite possible that the master backend has errored out before
      advancing the scan and issued a termination signal for all workers.  The
      workers failed to notice the termination request during wait because the
      interrupts are held due to buffer lock on the previous page.  This lead to
      all workers being stuck.
      
      The fix is to release the buffer lock on current page before trying to get
      the next page.  We are already doing same in backward scans, but missed
      it for forward scans.
      
      Reported-by: Victor Yegorov
      Bug: 15290
      Diagnosed-by: Thomas Munro and Amit Kapila
      Author: Amit Kapila
      Reviewed-by: Thomas Munro
      Tested-By: Thomas Munro and Victor Yegorov
      Backpatch-through: 10 where parallel index scans were introduced
      Discussion:https://postgr.es/m/153228422922.1395.1746424054206154747@wrigleys.postgresql.org
    nbtsearch.c 58.64 KiB