Re: Thread-unsafe coding in ecpg - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Thread-unsafe coding in ecpg
Date
Msg-id 23046.1547943059@sss.pgh.pa.us
Whole thread Raw
In response to Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
Responses Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
Michael Meskes <meskes@postgresql.org> writes:
>> IOW, not only is setlocale() not necessarily thread-safe itself,
>> but using it to change locales in a multithread program is seriously
>> unsafe because of concurrent effects on other threads.

> Agreed.

> How about attached patch? According to my manpages it should only
> affect the calling threat. I only tested it on my own system so far.
> Could you please have a look and/or test on other systems? 

Yeah, I was wondering about uselocale() myself.  We cannot assume it's
available everywhere, but it should fix the problem where available.
On machines that don't have it, we could either

(a) have ecpg do nothing, and just hope you're not using a dangerous
locale; or

(b) consider the platform not thread-safe, forcing people to specify
--disable-thread-safety to build.

While (b) has more theoretical purity, I'm inclined to think it
doesn't really improve anybody's life compared to (a), because
--disable-thread-safety doesn't actually stop anyone from using
libpq or ecpglib in threaded environments.  It just makes it
more likely to fail when they do.

The OpenBSD 6.4 platform where I found this problem has uselocale
(but the man page notes they only added it as of 6.2).  I can test
out the patch there, but I think the interesting questions are all
about what to do on platforms without the function.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Donald Dong
Date:
Subject: Re: Ryu floating point output patch
Next
From: Andrew Gierth
Date:
Subject: Re: pg_stat_statements vs. SELECT FOR UPDATE