| From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org>, <pgsql-hackers-win32(at)postgresql(dot)org> |
| Subject: | Re: unexpected and reproducable crash in pl/pgsql function |
| Date: | 2005-03-03 21:28:01 |
| Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3412A7638@Herge.rcsinc.local |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-hackers-win32 |
> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> > Ok, problem was due to recursive pl/pgsql function and a recursion
loop
> > in the data. I traced this problem to the data: somebody disabled
the
> > recursion check constraint.
> > I've never had this actually happen before. It totally nuked the
> > server.
>
> I thought we'd fixed things so that the stack depth on Windows is
> actually greater than max_stack_depth? None of this weirdness could
> happen if the stack depth check were kicking in properly.
I thought so too. I'll play with it a bit and see what I come up with.
Merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-03-03 22:05:40 | Solving hash table overrun problems |
| Previous Message | Tom Lane | 2005-03-03 21:20:00 | Re: unexpected and reproducable crash in pl/pgsql function |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ken Egervari | 2005-03-03 23:42:46 | Re: Help with tuning this query (with explain analyze finally) |
| Previous Message | Tom Lane | 2005-03-03 21:20:00 | Re: unexpected and reproducable crash in pl/pgsql function |