Re: Consistent segfault in complex query

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kyle Samson <kysamson(at)tripadvisor(dot)com>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Matthew Kelly <mkelly(at)tripadvisor(dot)com>
Subject: Re: Consistent segfault in complex query
Date: 2018-09-12 16:13:13
Message-ID: 87d0tipuhe.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Andrew" == Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-12 16:14:00 Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT
Previous Message Andrew Gierth 2018-09-12 16:08:08 Re: Consistent segfault in complex query