Re: Consistent segfault in complex query - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Consistent segfault in complex query
Date
Msg-id 87d0tipuhe.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Consistent segfault in complex query  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Consistent segfault in complex query  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Tom> The reason this seems possibly different is that we're apparently
 Tom> returning wrong data out of the sub-select (a zero Datum value,
 Tom> but not marked isnull --- if it were, arraycontains wouldn't be
 Tom> reached). The previously fixed bug would have caused either
 Tom> multiple or missed returns of a valid CTE tuple.

 Andrew> I have some ideas as to why, and I'm poking at them in order to
 Andrew> create a test case (no luck yet, but I'll keep at it).

Bingo - I have a test case, which I'll post in a sec after testing it on
other versions.

The key in this case is that the EPQ is the _first_ time the InitPlan is
executed - you need a construct like this:

  case when flag then foo when foo @> (select ... from cte) then foo end

such that flag is true on the initially visible row version (hence the
initplan is not run yet), but false on the modified version (hence
running the initplan during EPQ).

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Consistent segfault in complex query
Next
From: Tom Lane
Date:
Subject: Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT