Re: Thread-unsafe coding in ecpg

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Thread-unsafe coding in ecpg
Дата
Msg-id 23046.1547943059@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
Ответы Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: Donald Dong
Дата:
Сообщение: Re: Ryu floating point output patch
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: pg_stat_statements vs. SELECT FOR UPDATE