Re: Cleaning up threading code

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Cleaning up threading code
Дата
Msg-id ee52b872-bcc7-a181-c537-2dc6662308da@eisentraut.org
обсуждение исходный текст
Ответ на Re: Cleaning up threading code  (Andres Freund <andres@anarazel.de>)
Ответы Re: Cleaning up threading code  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On 10.06.23 07:26, Andres Freund wrote:
>> -###############################################################
>> -# Threading
>> -###############################################################
>> -
>> -# XXX: About to rely on thread safety in the autoconf build, so not worth
>> -# implementing a fallback.
>> -cdata.set('ENABLE_THREAD_SAFETY', 1)
> 
> I wonder if we should just unconditionally set that in c.h or such? It'd not
> be crazy for external projects to rely on that being set.

We definitely should keep the mention in ecpg_config.h.in, since that is 
explicitly put there for client code to use.  We keep HAVE_LONG_LONG_INT 
etc. there for similar reasons.

Another comment on patch 0003:  I think this removal in configure.ac is 
too much:

-    else
-      LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS"

This could would still be reachable for $enable_thread_safety=yes and 
$thread_safe_libldap=yes, which I suppose is the normal case?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench: option delaying queries till connections establishment?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add information about command path and version of flex in meson output