From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brendan Jurd <direvus(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Segfault in 9.0 inlining SRF |
Date: | 2010-10-24 20:36:10 |
Message-ID: | 16665.1287952570@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Brendan Jurd <direvus(at)gmail(dot)com> writes:
> I have encountered a reproducible segfault in Postgres, and confirmed
> it in 9.0.1 and HEAD on three separate machines. The bug was not
> present in 8.4. I've attached a copy of the SQL script I have been
> using to induce the segfault.
> ...
> I had a go at investigating the cause of the bug, but didn't have much
> success as I'm not at all familiar with the guts of the optimizer.
Looks like the invalItems list has been clobbered:
(gdb) p *root->glob->invalItems
$6 = {type = 2139062143, length = 2139062143, head = 0x7f7f7f7f,
tail = 0x7f7f7f7f}
I'm guessing it was modified in the temporary memory context and not
properly copied out to the parent context when we finished inlining
the function.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2010-10-24 21:25:58 | Re: Segfault in 9.0 inlining SRF |
Previous Message | Brendan Jurd | 2010-10-24 20:13:46 | Segfault in 9.0 inlining SRF |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-10-24 20:53:30 | Re: typenameTypeId refactoring |
Previous Message | Brendan Jurd | 2010-10-24 20:13:46 | Segfault in 9.0 inlining SRF |