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

configure

Blame
    • Tom Lane's avatar
      6106f9dd
      Avoid thread-safety problem in ecpglib. · 6106f9dd
      Tom Lane authored
      ecpglib attempts to force the LC_NUMERIC locale to "C" while reading
      server output, to avoid problems with strtod() and related functions.
      Historically it's just issued setlocale() calls to do that, but that
      has major problems if we're in a threaded application.  setlocale()
      itself is not required by POSIX to be thread-safe (and indeed is not,
      on recent OpenBSD).  Moreover, its effects are process-wide, so that
      we could cause unexpected results in other threads, or another thread
      could change our setting.
      
      On platforms having uselocale(), which is required by POSIX:2008,
      we can avoid these problems by using uselocale() instead.  Windows
      goes its own way as usual, but we can make it safe by using
      _configthreadlocale().  Platforms having neither continue to use the
      old code, but that should be pretty much nobody among current systems.
      
      (Subsequent buildfarm results show that recent NetBSD versions still
      lack uselocale(), but it's not a big problem because they also do not
      support non-"C" settings for LC_NUMERIC.)
      
      Back-patch of commits 8eb4a931 and ee27584c.
      
      Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa.
      
      Discussion: https://postgr.es/m/31420.1547783697@sss.pgh.pa.us
      6106f9dd
      History
      Avoid thread-safety problem in ecpglib.
      Tom Lane authored
      ecpglib attempts to force the LC_NUMERIC locale to "C" while reading
      server output, to avoid problems with strtod() and related functions.
      Historically it's just issued setlocale() calls to do that, but that
      has major problems if we're in a threaded application.  setlocale()
      itself is not required by POSIX to be thread-safe (and indeed is not,
      on recent OpenBSD).  Moreover, its effects are process-wide, so that
      we could cause unexpected results in other threads, or another thread
      could change our setting.
      
      On platforms having uselocale(), which is required by POSIX:2008,
      we can avoid these problems by using uselocale() instead.  Windows
      goes its own way as usual, but we can make it safe by using
      _configthreadlocale().  Platforms having neither continue to use the
      old code, but that should be pretty much nobody among current systems.
      
      (Subsequent buildfarm results show that recent NetBSD versions still
      lack uselocale(), but it's not a big problem because they also do not
      support non-"C" settings for LC_NUMERIC.)
      
      Back-patch of commits 8eb4a931 and ee27584c.
      
      Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa.
      
      Discussion: https://postgr.es/m/31420.1547783697@sss.pgh.pa.us