| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Paulo Jan <admin(at)mail(dot)ddnet(dot)es> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Query hangs when getting too complex... |
| Date: | 2001-12-19 18:56:41 |
| Message-ID: | 1996.1008788201@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Paulo Jan <admin(at)mail(dot)ddnet(dot)es> writes:
> Here it is, but it looks the same to me:
No, it's not the same at all...
> #0 0x80d58d7 in pprint ()
> #1 0x80fc729 in pg_parse_and_rewrite ()
> #2 0x80fc9a1 in pg_exec_query_string ()
> #3 0x80fdab6 in PostgresMain ()
[ eyeballs pprint ] Oh my. Nothing like a fixed-size buffer to blow up
on you :-(. pprint will crash and burn if indentLev exceeds 80/3, and
I'll bet that's exactly what's happening on your complex query. Wonder
why no one noticed this before?
Try turning down your debug level so that the detailed query plan
doesn't get dumped. In the meantime, I'll do something to fix this
for 7.2.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-12-19 19:02:32 | Re: Can't use subselect in check constraint |
| Previous Message | Paulo Jan | 2001-12-19 18:56:22 | Re: Query hangs when getting too complex... |