From: | Fernando Schapachnik <fernando(at)mecon(dot)gov(dot)ar> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Infinite loop in transformExpr() |
Date: | 2007-02-23 15:00:19 |
Message-ID: | 20070223150019.GE863@bal740r0.mecon.gov.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
En un mensaje anterior, Tom Lane escribió:
> PG versions before 8.2 don't handle very long IN lists particularly
> well. This query will take a fair amount of stack space to parse, not
> to mention an unreasonably long time to plan. (You should consider
> putting the 16000 values in a temp table and doing a join, instead.)
Thanks for the tip!
[...]
> Most likely, the production machine has a kernel-enforced stack limit
> setting that is less than what "max_stack_depth" claims. Up till recently
> (8.2 I think), we didn't make any effort to verify that "max_stack_depth"
> was set to a sane value. If it's too high you will get crashes rather
> than "stack depth limit exceeded", because overrunning the kernel limit
> is typically treated as a SIGSEGV.
[...]
> Hm. It would appear that you are loading some custom code that sucks
> pthread support into the backend. This is generally a bad idea in any
Not really. Only PLSQL and dblink. Anyway, my understanding is that
this should be already fixed in 8.2 and is not worth looking deeply,
right?
Thanks for your help.
Fernando.
From | Date | Subject | |
---|---|---|---|
Next Message | djé djé | 2007-02-23 15:05:42 | false unique constraint error...for me |
Previous Message | Tom Lane | 2007-02-23 14:59:44 | Re: Warning "TupleDesc reference leak" |