I think we have an old issue in the (old) postgres module which may be serious enough to fix in 7.8 before the release.
Most of my systems doesn't have postgresql installed, but the other day I installed 8.3 on my laptop.
Today I checked out a fresh 7.8 and ran make. Everything ran smooth until it tried to compile the postgres module, where it failed.
Looking at the error, it was pretty obvious that linking failed because of clashing symbols. Further investigation lead me to conclude that both pgresult.c and postgres.c seems to define pike_postgres_mutex if the postgres library isn't thread-safe. This is the first problem. Both source files cannot define this symbol, and since it should only be defined when the library isn't thread-safe, I believe on of them should simply be turned into an extern.
Changing the definition in pgresult.c to a simple extern makes the module compile.
Now, I went on to investigate why my postgres libs weren't thread-safe. I would assume most libraries *ARE* thread-safe on modern platforms, so I found it kind of strange.
After lots of digging, I found that we look for the function PQsetnonblocking() to determine if the library is thread-safe. This seems somewhat stupid, so I would propose that we also introduce a configure test to properly check if the library is reentrant by actually calling PQisthreadsafe(), with a fallback to the current test, in case older libs doesn't support that function.
The whole thing seems to be caused by my postgres libs beeing installed from ports and not correctly found by Pike, which causes some confusion. If we are to keep the old module around for a prolonged period, we may want to clean up it's configure tests in general.
For now, I do believe that the first issue has to be fixed before the 7.8 release, since it actually prevented me from compiling Pike, while the latter can probably be left out for now.
Marcus Agehall (Roxen IS) @ Pike (-) developers forum wrote:
I think we have an old issue in the (old) postgres module which may be serious enough to fix in 7.8 before the release.
that both pgresult.c and postgres.c seems to define pike_postgres_mutex if the postgres library isn't thread-safe. This is
Changing the definition in pgresult.c to a simple extern makes the module compile.
Committed this now.
After lots of digging, I found that we look for the function PQsetnonblocking() to determine if the library is thread-safe. This seems somewhat stupid, so I would propose that we also introduce a configure test to properly check if the library is reentrant by actually calling PQisthreadsafe(), with a fallback to the current test, in case older libs doesn't support that function.
I'm not that proficient with configure magic, and since the old Postgres module is a likely candidate to be deprecated/dropped in the near future, it seems like a waste of time to spend the effort.
I have a patch for the configure problem too, but I'm a bit reluctant to commit it now, since it's more a nice-to-have-thing and a you said, we may not be using it for much longer.
Besides, the problem should have been in the module for several years if I read the cvs logs correctly, so the mere fact that noone else has reported it as a problem indicates that it isn't much of an issue.
pike-devel@lists.lysator.liu.se