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
>
Bruce Momjian wrote:
Sinisa Zivanovic wrote:
The following bug has been logged online:
Bug reference: 1476
Logged by: Sinisa Zivanovic
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.2
Operating system: SuSE 8.2
Description:on Xeon 2.8 can't instaling source
"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.
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Can defaults be set to the result of a function?
By "power-on default" I mean the value that the variable is assigned as
its static initializer. That has to be a link-time constant (at least
in C ...). Anything else will mean misbehavior if an erro
> > On another note, is it really good for guc to be calling ereport()
> > before it has loaded the config options for ereport,
>
> We don't have much choice. This is why the power-up defaults
> have to be at least somewhat sane for the platform.
It could use write_stderr() if it fails the fir
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> On another note, is it really good for guc to be calling ereport()
> before it has loaded the config options for ereport,
We don't have much choice. This is why the power-up defaults have to be
at least somewhat sane for the platform.
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
> > I checked all logs I could think of (event and pg_logs) and
> found no
> > information. I suppose if I tried starting postmaster by
> hand I would
> > have spotted the issue.
>
> Hmm. I see at least part of the problem: the poweron default
> for log_destination is "stderr" which is not
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
> The following bug has been logged online:
>
> Bug reference: 1475
> Logged by: Luciano Almeida
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0
> Operating system: Windows XP
> Description:error to install language pltcl
> Details:
>
> Hello
> I'm f
20 matches
Mail list logo
