Horton

Re: Thread-unsafe coding in ecpg

Andrew Gierth <andrew@tao11.riddles.org.uk>

View thread View on postgr.es
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Michael Meskes <meskes@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2019-01-20T01:32:50Z
Lists: pgsql-hackers 
>>>>> "Michael" == Michael Meskes <meskes@postgresql.org> writes:

 >> Therefore, it's plain crazy for ecpg to be calling setlocale()
 >> inside threaded code. It looks to me like what ecpg is doing is
 >> trying to defend itself against non-C LC_NUMERIC settings, which is
 >> laudable, but this implementation of that is totally unsafe.
 >> 
 >> Don't know what's the best way out of this.  The simplest thing would
 >> be to just remove that code and document that you'd better run ecpg
 >> in LC_NUMERIC locale, but it'd be nice if we could do better.

Would it help if we had non-locale-aware functions for both
floating-point output _and_ input? i.e. import a known-working strtod()
(allowing us to remove all the hacks that have grown up around it, for
special-case input and wonky error handling) with locale functionality
removed.

-- 
Andrew (irc:RhodiumToad)

Commits

  1. Remove _configthreadlocale() calls in ecpg test suite.

  2. Remove infinite-loop hazards in ecpg test suite.

  3. Blind attempt to fix _configthreadlocale() failures on MinGW.

  4. Avoid thread-safety problem in ecpglib.

  5. Second try at fixing ecpglib thread-safety problem.