Skip site navigation (1) Skip section navigation (2)

Re: Segfault in 9.0 inlining SRF

From: Brendan Jurd <direvus(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 21:25:58
Message-ID: AANLkTi=oZDB1+Q_=gsy4jTmZEmO-4YxzWv6twNBbAGgJ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On 25 October 2010 07:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I note that the error goes away if I do any of the following with my test case:

 a) define the SRF as having no arguments, or
 b) make the argument passed into the SRF a constant rather than a
call to a function, or
 c) make the argument function (year) itself take no arguments, or
 d) make the argument passed to year a constant rather than current_date, or
 e) define year as VOLATILE, or
 f) put the call to segfault_setof into a subquery in the FROM clause.

So this only manifests under a pretty specific type of query tree; a
function call as the argument to another function call, which is an
argument to an inlinable SRF in FROM.

Cheers,
BJ

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-10-24 21:34:16
Subject: Re: WIP: extensible enums
Previous:From: Andrew DunstanDate: 2010-10-24 21:24:07
Subject: Re: WIP: extensible enums

pgsql-bugs by date

Next:From: Dharmendra GoyalDate: 2010-10-25 05:03:49
Subject: Re: BUG
Previous:From: Tom LaneDate: 2010-10-24 20:36:10
Subject: Re: Segfault in 9.0 inlining SRF

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group