I haven't been following this thread closely, but if I understand
correctly then the problems are the result of linking PostgreSQL
against libc_r instead of libc on FreeBSD (at least FreeBSD 4.x),
which was done in an attempt to make plpythonu work. Otherwise
attempting to createlang plpythonu res
"Brian B." <[EMAIL PROTECTED]> writes:
> You may be onto something, there. After doing some searching, I have
> found the FreeBSD thread stack size as a default of 64KB!
Ugh :-(. That might be reasonable for a program that's actually using
multiple threads, but a program that is not thread-aware
On Fri, Feb 11, 2005 at 10:33:00PM -0500, Tom Lane wrote:
> BTW, something that would be interesting is to figure out what the
> thread stack size actually is (I assume this is available in the FreeBSD
> docs) and experiment to find what is the maximum value max_stack_depth
> can be set to without
BTW, something that would be interesting is to figure out what the
thread stack size actually is (I assume this is available in the FreeBSD
docs) and experiment to find what is the maximum value max_stack_depth
can be set to without letting infinite_recurse() dump core.
reg
On Fri, Feb 11, 2005 at 10:05:36PM -0500, Tom Lane wrote:
> "Brian B." <[EMAIL PROTECTED]> writes:
> > When setting the "LIBC_R" option, the FreeBSD port essentially sets CFLAGS
> > to
> > -D_THREAD_SAFE and LDFLAGS to -pthread. This is probably due to the Python
> > procedural handler not being a
"Brian B." <[EMAIL PROTECTED]> writes:
> When setting the "LIBC_R" option, the FreeBSD port essentially sets CFLAGS to
> -D_THREAD_SAFE and LDFLAGS to -pthread. This is probably due to the Python
> procedural handler not being able to link with PostgreSQL until PostgreSQL
> is built pthread-aware.
On Fri, Feb 11, 2005 at 09:46:50PM -0500, Tom Lane wrote:
> "Brian B." <[EMAIL PROTECTED]> writes:
> > I use the FreeBSD PostgreSQL port and I set the option to use threads so
> > that pl/python will work with PostgreSQL.
>
> What option is that, exactly?
>
> It's entirely possible that something
"Brian B." <[EMAIL PROTECTED]> writes:
> I use the FreeBSD PostgreSQL port and I set the option to use threads so
> that pl/python will work with PostgreSQL.
What option is that, exactly?
It's entirely possible that something has decided that the backend is
going to be multithreaded and is only g
On Fri, Feb 11, 2005 at 06:54:31PM -0500, I wrote:
> Yup ... that's really close. I'm going to do a few tests to try to figure
> out what's going on with my environment and let you know if I come up with
> anything odd.
I think I have figured out the culprit.
I use the FreeBSD PostgreSQL port and
On Fri, Feb 11, 2005 at 06:46:55PM -0500, Tom Lane wrote:
> >> Did you happen to test with FreeBSD on one of your test machines?
>
> > No, I don't have any BSD machines here. However, I've added this test
> > case to the regression tests, so in a few hours we'll have a spectrum
> > of results fro
>> Did you happen to test with FreeBSD on one of your test machines?
> No, I don't have any BSD machines here. However, I've added this test
> case to the regression tests, so in a few hours we'll have a spectrum
> of results from the PG build farm.
FWIW, I see a "pass" from buildfarm member coc
"Brian B." <[EMAIL PROTECTED]> writes:
> Did you happen to test with FreeBSD on one of your test machines?
No, I don't have any BSD machines here. However, I've added this test
case to the regression tests, so in a few hours we'll have a spectrum
of results from the PG build farm.
On Fri, Feb 11, 2005 at 04:56:16PM -0500, Tom Lane wrote:
> regression=# create function infinite_recurse() returns int as '
> regression'# select infinite_recurse()' language sql;
> regression=# \set VERBOSITY terse
> regression=# select infinite_recurse();
> ERROR: stack depth limit exceeded
>
"Brian B." <[EMAIL PROTECTED]> writes:
>> See debug_query_string.
> I've got the gdb output of printing debug_query_string and the text saved
> from script(1) is about 267KB in size. Should I send this to you off-list?
Please. Also I'll need the schemas for the tables the query uses.
On Thu, Feb 10, 2005 at 05:24:12PM -0500, Tom Lane wrote:
> Hmm, 64meg should certainly be far past where check_stack_depth will
> start to complain, so there's something else going on here. (BUT:
> the ulimits you see interactively aren't necessarily what the postmaster
> was started under. You
Tom Lane wrote:
Hmm, 64meg should certainly be far past where check_stack_depth will
start to complain, so there's something else going on here.
Right; if those really are the stack size limits for the crashing
backend, I guess my initial analysis must have been mistaken. But I'm
mystified as to
"Brian B." <[EMAIL PROTECTED]> writes:
> On Thu, Feb 10, 2005 at 10:08:14AM -0500, Tom Lane wrote:
>> There is a check_stack_depth call in there, so this could only be the
>> explanation if max_stack_depth is set too high for the actual
>> stack depth limit. What's the platform, and what ulimit va
Hello,
On Thu, Feb 10, 2005 at 10:08:14AM -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > It seems what's happening here is that dspam is submitting a query with
> > many thousands of elements in the IN clause. In the parser, we transform
> > "foo IN (a, b, c)" into "foo = a O
Neil Conway <[EMAIL PROTECTED]> writes:
> It seems what's happening here is that dspam is submitting a query with
> many thousands of elements in the IN clause. In the parser, we transform
> "foo IN (a, b, c)" into "foo = a OR foo = b OR foo = c", and then
> recurse for each element of the OR expre
"Brian B." <[EMAIL PROTECTED]> writes:
> I am loading some spam/ham data/tokens, to be used for the dspam anti-spam
> software, into PostgreSQL. After a few hours of inserting and updating the
> existing data, the backend crashes with a signal 10 (bus error).
Judging by the trace, this doesn't dep
> It seems what's happening here is that dspam is submitting a
> query with many thousands of elements in the IN clause. In
> the parser, we transform "foo IN (a, b, c)" into "foo = a OR
> foo = b OR foo = c", and then recurse for each element of the
> OR expression and eventually run out of st
On Thu, 2005-02-10 at 02:37 +, Brian B. wrote:
> I am loading some spam/ham data/tokens, to be used for the dspam anti-spam
> software, into PostgreSQL. After a few hours of inserting and updating the
> existing data, the backend crashes with a signal 10 (bus error). I am also
> running an ANAL
The following bug has been logged online:
Bug reference: 1473
Logged by: Brian B.
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: FreeBSD 4.11-STABLE
Description:Backend bus error, possibly due to ANALYZE
Details:
Hello,
I am loading so
23 matches
Mail list logo
