James Mansion wrote:
> I think you have your head in the ground, but its your perogative.
> *You* might not care, but anyone wanting to use thread-aware libraries
> (and I'm *not* talking about threading in any Postgres code) will
> certainly value it if they can do so with some stability.
I sugge
Tom Lane wrote:
Yes.
1) It's of no value to us
2) On many platforms there is a nonzero performance penalty
I think you have your head in the ground, but its your perogative. *You*
might not care, but anyone wanting to use thread-aware libraries (and I'm
*not* talking about threading in an
"Craig James" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> And the only reason to do that would be to work around one bug in one small
>> range of glibc versions. If you're going to use a multi-threaded library
>> (which isn't very common since it's hard to do safely for all those other
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
James Mansion <[EMAIL PROTECTED]> writes:
Is there any particular reason not to ensure that any low-level
threading support in libc is enabled right
from the get-go, as a build-time option?
Yes.
1) It's of no value to us
Who is "u
"Tom Lane" <[EMAIL PROTECTED]> writes:
> James Mansion <[EMAIL PROTECTED]> writes:
>> Is there any particular reason not to ensure that any low-level
>> threading support in libc is enabled right
>> from the get-go, as a build-time option?
>
> Yes.
> 1) It's of no value to us
> 2) On many platfor
James Mansion <[EMAIL PROTECTED]> writes:
> Is there any particular reason not to ensure that any low-level
> threading support in libc is enabled right
> from the get-go, as a build-time option?
Yes.
1) It's of no value to us
2) On many platforms there is a nonzero performance penalty
Gregory Stark wrote:
1) No Postgres function is guaranteed to be thread-safe so you better protect
against concurrent calls to Postgres API functions. Also Postgres functions
use longjmp which can restore the stack pointer to a value which may have
been set earlier, possibly by another t
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> I can find no such text in our documentation at all, nor any reference
>> to OpenBabel. I think Craig must be looking at someone else's
>> documentation.
> It's actually 33.9.6 and it is in:
> http://www.postgresql.org/docs/8.2/static/xfunc-c.html#
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>
>> This should be amended to say,
>>
>> "To be precise, a non-threaded, shared library needs to be created."
>
> Just before someone goes ahead and writes it (which is probably a good i
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
Since I'm not a Postgres developer, perhaps one of the maintainers could
update the Postgres manual. In chapter 32.9.6, it says,
"To be precise, a shared library needs to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Dec 2007 11:25:08 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
> >> Since I'm not a Postgres developer, perhaps one of the maintaine
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>> Since I'm not a Postgres developer, perhaps one of the maintainers could
>> update the Postgres manual. In chapter 32.9.6, it says,
>>
>> "To be precise, a shared library needs to be cre
Craig James <[EMAIL PROTECTED]> writes:
>> Please show that stuff you snipped --- it might have some relevant
>> information. The stack trace looks a bit like a threading problem...
> Using host libthread_db library "/lib/libthread_db.so.1".
That's pretty suspicious, but not quite a smoking gun.
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Craig James wrote:
>> Can you elaborate? Are multithreaded libraries not allowed to be
>> linked to Postgres?
> Absolutely not.
The problem is that you get into library-interaction bugs like the
one discussed here:
http://archives.postgresql.org/pgsql
On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
> Alvaro Herrera wrote:
> >>>...Since you've now shown that OpenBabel is
> >>>multithreaded, then that's a much more likely cause.
> >>Can you elaborate? Are multithreaded libraries not allowed to be
> >>linked to Postgres?
> >
> >Absolu
Tom Lane wrote:
Craig James <[EMAIL PROTECTED]> writes:
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions
Alvaro Herrera wrote:
...Since you've now shown that OpenBabel is
multithreaded, then that's a much more likely cause.
Can you elaborate? Are multithreaded libraries not allowed to be
linked to Postgres?
Absolutely not.
Ok, thanks, I'll work on recompiling OpenBabel without thread support.
Craig James <[EMAIL PROTECTED]> writes:
> GNU gdb Red Hat Linux (6.5-15.fc6rh)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> [snip
Craig James wrote:
> Alvaro Herrera wrote:
>> Craig James wrote:
>>> Alvaro Herrera wrote:
Craig James wrote:
> Here is my guess -- and this is just a guess. My functions use a
> third-party library which, of necessity, uses malloc/free in the
> ordinary way. I suspect that
Alvaro Herrera wrote:
Craig James wrote:
Alvaro Herrera wrote:
Craig James wrote:
Here is my guess -- and this is just a guess. My functions use a
third-party library which, of necessity, uses malloc/free in the
ordinary way. I suspect that there's a bug in the Postgres palloc()
code that's
Craig James wrote:
> Alvaro Herrera wrote:
>> Craig James wrote:
>>
>>> Here is my guess -- and this is just a guess. My functions use a
>>> third-party library which, of necessity, uses malloc/free in the
>>> ordinary way. I suspect that there's a bug in the Postgres palloc()
>>> code that's wal
Alvaro Herrera wrote:
Craig James wrote:
Here is my guess -- and this is just a guess. My functions use a
third-party library which, of necessity, uses malloc/free in the
ordinary way. I suspect that there's a bug in the Postgres palloc()
code that's walking over memory that regular malloc()
Craig James wrote:
> Here is my guess -- and this is just a guess. My functions use a
> third-party library which, of necessity, uses malloc/free in the
> ordinary way. I suspect that there's a bug in the Postgres palloc()
> code that's walking over memory that regular malloc() allocates. The
>
Tom Lane wrote:
Craig James <[EMAIL PROTECTED]> writes:
This is driving me crazy. I have some Postgres C function extensions in a
shared library. They've been working fine. I upgraded to Fedora Core 6 and
gcc4, and now every time psql(1) disconnects from the server, the serverlog
gets this
Craig James <[EMAIL PROTECTED]> writes:
> This is driving me crazy. I have some Postgres C function extensions in a
> shared library. They've been working fine. I upgraded to Fedora Core 6 and
> gcc4, and now every time psql(1) disconnects from the server, the serverlog
> gets this message:
>
Alvaro Herrera wrote:
Craig James wrote:
This is driving me crazy. I have some Postgres C function extensions
in a shared library. They've been working fine. I upgraded to Fedora
Core 6 and gcc4, and now every time psql(1) disconnects from the
server, the serverlog gets this message:
*** g
Craig James wrote:
> This is driving me crazy. I have some Postgres C function extensions
> in a shared library. They've been working fine. I upgraded to Fedora
> Core 6 and gcc4, and now every time psql(1) disconnects from the
> server, the serverlog gets this message:
>
> *** glibc detected
This is driving me crazy. I have some Postgres C function extensions in a
shared library. They've been working fine. I upgraded to Fedora Core 6 and
gcc4, and now every time psql(1) disconnects from the server, the serverlog
gets this message:
*** glibc detected *** postgres: mydb mydb [l
28 matches
Mail list logo
