Re: Thread-unsafe coding in ecpg

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Andrew Dunstan <andrew@dunslane.net>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Michael Meskes <meskes@postgresql.org>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-21T20:45:04Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> We could just refuse to support thread safety on mingw if that's not
> supported? Or is that too aggressive?

Nah, we already had that discussion upthread.  Given the lack of
prior complaints, we shouldn't break cases that are working today.

For instance, as long as setlocale() isn't actively thread-unsafe
and you are running with LC_NUMERIC=C as the prevailing locale,
the existing code doesn't pose a hazard even in a threaded app.
Forcing users for whom that's true to --disable-thread-safety
would turn an OK situation into a broken one.

			regards, tom lane


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.