Aim of --enable-thread-safety ?
Hello List,
I wonder if this compilation option is really taken into account as
PostgreSQL is not multi-threading but multi-processing.
I have read that without this option, the libpq won't know anything
about threads and may indeed have problems, but could you explain me how
this option runs ?
It is not clear for me the aim of this option in an multi-processing
environment...
Is it possible to force PostgreSQL to be multi-threaded ?
Thank you for your help.
Regards,
Alexandra DANTE
On Mon, Jul 10, 2006 at 11:47:06AM +0200, DANTE Alexandra wrote:
Hello List,
I wonder if this compilation option is really taken into account as
PostgreSQL is not multi-threading but multi-processing.
I have read that without this option, the libpq won't know anything
about threads and may indeed have problems, but could you explain me how
this option runs ?
It enables thread-safety in client libraries. If you don't do this then
the client libraries will behave strangly when used in multi-threaded
programs.
As an example, consider the "errno" variable. It's a global variable,
which obviously doesn't work well in multi-threaded programs. When you
enable thread-safety it becomes a thread-local variable. The C library
has a number of things like that (locale, timezone, strtok, etc).
In modern systems it should always be on for libraries. There's is no
way to guarentee your library won't be used in a multithreaded program
and the cost is marginal. Really, the option should be changed to
default to on.
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Hello Martijn,
Thank you for your answer.
Just to be sure, the "--enable-thread-safety" option allows client
libraries, which connect via libpq to a PostgreSQL database, to be
multi-threaded, but each "postgres" process launched to etablish the
connection is not multi-threaded. Consequently, PostgreSQL can not
execute a query in several CPU, the source code of PostgreSQL is not
multi-threaded.
Is it correct ?
Thank you very much for your help.
Regards,
Alexandra
Martijn van Oosterhout wrote:
Show quoted text
On Mon, Jul 10, 2006 at 11:47:06AM +0200, DANTE Alexandra wrote:
Hello List,
I wonder if this compilation option is really taken into account as
PostgreSQL is not multi-threading but multi-processing.
I have read that without this option, the libpq won't know anything
about threads and may indeed have problems, but could you explain me how
this option runs ?It enables thread-safety in client libraries. If you don't do this then
the client libraries will behave strangly when used in multi-threaded
programs.As an example, consider the "errno" variable. It's a global variable,
which obviously doesn't work well in multi-threaded programs. When you
enable thread-safety it becomes a thread-local variable. The C library
has a number of things like that (locale, timezone, strtok, etc).In modern systems it should always be on for libraries. There's is no
way to guarentee your library won't be used in a multithreaded program
and the cost is marginal. Really, the option should be changed to
default to on.Hope this helps,
Alexandra.Dante@bull.net (DANTE Alexandra) wrote:
I wonder if this compilation option is really taken into account as
PostgreSQL is not multi-threading but multi-processing.
I have read that without this option, the libpq won't know anything
about threads and may indeed have problems, but could you explain me
how this option runs ?
It is not clear for me the aim of this option in an multi-processing
environment...
Is it possible to force PostgreSQL to be multi-threaded ?
This option is all about allowing you to have multi-threaded *client*
applications.
That is, applications that many have multiple threads where threads
can hold onto database connections.
--
(format nil "~S@~S" "cbbrowne" "linuxfinances.info")
http://cbbrowne.com/info/internet.html
Q: How many Newtons does it take to change a light bulb?
A: Faux! There to eat lemons, axe gravy soup!
Christopher Browne wrote:
Alexandra.Dante@bull.net (DANTE Alexandra) wrote:
I wonder if this compilation option is really taken into account as
PostgreSQL is not multi-threading but multi-processing.
I have read that without this option, the libpq won't know anything
about threads and may indeed have problems, but could you explain me
how this option runs ?It is not clear for me the aim of this option in an multi-processing
environment...
Is it possible to force PostgreSQL to be multi-threaded ?This option is all about allowing you to have multi-threaded *client*
applications.That is, applications that many have multiple threads where threads
can hold onto database connections.
Uh, the documentation is very clear on the purpose of this option:
<term><option>--enable-thread-safety</option></term>
<listitem>
<para>
Make the client libraries thread-safe. This allows
concurrent threads in <application>libpq</application> and
<application>ECPG</application> programs to safely control
their private connection handles. This option requires adequate
threading support in your operating system.
Is there something unclear about it?
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Mon, Jul 10, 2006 at 01:39:44PM -0400, Bruce Momjian wrote:
Uh, the documentation is very clear on the purpose of this option:
<term><option>--enable-thread-safety</option></term>
<listitem>
<para>
Make the client libraries thread-safe. This allows
concurrent threads in <application>libpq</application> and
<application>ECPG</application> programs to safely control
their private connection handles. This option requires adequate
threading support in your operating system.Is there something unclear about it?
Not sure. The way I read it, it doesn't say that it's also important
even if the multithreaded program only has one connection (it uses the
word "handles"). Someone posted a problem not so long ago where he'd
figured he didn't need thread-safety because he was only using one
connection, but it still broke if libpq was called from anything other
than the main thread.
If there is any possibility libpq is going to come in contact with a
multithreaded program (even via a loaded plugin or whatever) you must
have thread-safety enabled or things are likely to break.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.