Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom recently added a check for getrlimit(RLIMIT_STACK), but I don't know
> if that considered the "megabyte or so". *peeks the code* Yeah,
> there's a 512 kb "daylight", but there's also an absolute maximum of
> 2MB.
No, there's no absolute maximum (u
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> But I do not understand why the IN list has to make so many recursive
> calls???
Existing releases effectively expand "foo IN (1,2,3,...)" to
"(((foo = 1) OR foo = 2) OR foo = 3) ..." which can be a deeply
nested OR structure. IIRC this is changed in
But I do not understand why the IN list has to make so many recursive calls???I know if it was possible, it'd have been done already... but can 'making it iterative' (whatever 'it' stands for) be reconsidered?
-- [EMAIL PROTECTED][EMAIL PROTECTED] gmail | hotmail | yahoo }.com
On 11/2/06, Alvaro He
Markus Schiltknecht wrote:
> Hello Alvaro,
>
> yeah, thanks, that's it. postgresql.conf had:
>
> max_stack_depth = 8192 # min 100, size in KB
>
> I don't know who put it at 8192. According to the fine manual at [1], it
> should be set to something below 'ulimit -s', which gives
On Thu, Nov 02, 2006 at 05:16:40PM +0100, Markus Schiltknecht wrote:
> OTOH, having to configure such things is not exactly user friendly. I
> guess it's difficult to determine the stack limit in a cross-platform
> way. Or does having that configuration option other reasons for existence?
A patc
Hi,
Richard Huxton wrote:
If you can reliably reproduce it (I can't here - Debian on x86) - a
bug-report on the bugs mailing list or the website would probably be
appreciated by the developers. PG version, OS version, method of install
etc.
I've thought about that, but I somehow just *knew*
Hello Alvaro,
yeah, thanks, that's it. postgresql.conf had:
max_stack_depth = 8192 # min 100, size in KB
I don't know who put it at 8192. According to the fine manual at [1], it
should be set to something below 'ulimit -s', which gives 8192 on the
machine in question. I've no
Markus Schiltknecht wrote:
Hi,
One of our PostgreSQL 8.1.5 databases constantly crashed on a certain
query (backend SEGFAULTs). I've figured the crashes were caused by a
very long IN() clause.
(Sorry for replying twice in a row)
Could it be out-of-memory rather than a segfault you're seeing
Alvaro Herrera wrote:
> Markus Schiltknecht wrote:
> > Hi,
> >
> > One of our PostgreSQL 8.1.5 databases constantly crashed on a certain
> > query (backend SEGFAULTs). I've figured the crashes were caused by a
> > very long IN() clause.
> >
> > You can easily reproduce the crash by feeding the
Markus Schiltknecht wrote:
Hi,
thanks for testing, unfortunately I don't have a 8.0 around. And as 8.2
works and is probably coming very soon...
If you can reliably reproduce it (I can't here - Debian on x86) - a
bug-report on the bugs mailing list or the website would probably be
appreciat
Markus Schiltknecht wrote:
> Hi,
>
> One of our PostgreSQL 8.1.5 databases constantly crashed on a certain
> query (backend SEGFAULTs). I've figured the crashes were caused by a
> very long IN() clause.
>
> You can easily reproduce the crash by feeding the output of the python
> script below t
No segfault in 8.1.5 on win32 either...
- Original Message
From: Markus Schiltknecht <[EMAIL PROTECTED]>
To: Shelby Cain <[EMAIL PROTECTED]>
Cc: pgsql general
Sent: Thursday, November 2, 2006 9:55:08 AM
Subject: Re: [GENERAL] lots of values for IN() clause
Hi,
thanks
Hi,
thanks for testing, unfortunately I don't have a 8.0 around. And as 8.2
works and is probably coming very soon...
Regards
Markus
Shelby Cain wrote:
I don't get a segfault on 8.0.8 under linux or 8.1.4 under win32. The backend
(correctly I assume) issues a hint to increase max_stack_de
I don't get a segfault on 8.0.8 under linux or 8.1.4 under win32. The backend
(correctly I assume) issues a hint to increase max_stack_depth in both cases.
$ psql -h localhost -p 5432 -d test -U readwrite < script.sql
Password:
CREATE TABLE
ERROR: stack depth limit exceeded
HINT: Increase
14 matches
Mail list logo
