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 to your database.
Fortunately, 8.2 (as
the configuration parameter max_stack_depth.
DROP TABLE
Regards,
Shelby Cain
- Original Message
From: Markus Schiltknecht [EMAIL PROTECTED]
To: pgsql general pgsql-general@postgresql.org
Sent: Thursday, November 2, 2006 9:21:52 AM
Subject: [GENERAL] lots of values for IN() clause
Hi
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
No segfault in 8.1.5 on win32 either...
- Original Message
From: Markus Schiltknecht [EMAIL PROTECTED]
To: Shelby Cain [EMAIL PROTECTED]
Cc: pgsql general pgsql-general@postgresql.org
Sent: Thursday, November 2, 2006 9:55:08 AM
Subject: Re: [GENERAL] lots of values for IN() clause
Hi
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 to your
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
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 output of the
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
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
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*
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 patch
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 8192
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
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 8.2.
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 (unless I
15 matches
Mail list logo
