Re: Consistent segfault in complex query
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyle Samson <kysamson@tripadvisor.com>,
"pgsql-hackers\@postgresql.org" <pgsql-hackers@postgresql.org>,
Matthew Kelly <mkelly@tripadvisor.com>
Date: 2018-09-12T16:33:22Z
Lists: pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
Andrew> Bingo - I have a test case, which I'll post in a sec after
Andrew> testing it on other versions.
OK, not only does it break in latest 9.3 stable, it also breaks in
current master.
This is the testcase:
create table mytable (id integer, foo text[] default '{}', flag boolean default false);
insert into mytable select generate_series(1,10);
now in session B do:
begin; update mytable set foo='{baz}', flag=true where id=6;
-- leave transaction open
and in session A:
with tmp(f2) as (select array['foo'])
update mytable set foo = case when not flag then foo
when foo @> (select f2 from tmp) then foo
else foo || (select f2 from tmp) end
where id=6;
-- hangs on row lock
Then commit in session B, and watch A go down in flames.
Going to see if this can be narrowed down further.
--
Andrew (irc:RhodiumToad)
Commits
-
Fix failure with initplans used conditionally during EvalPlanQual rechecks.
- f13e2d1cec9b 11.0 landed
- 9b14bbd52c8c 9.5.15 landed
- 99cbbbbd1ddd 10.6 landed
- 8494755109e9 9.4.20 landed
- 591d0ac8858c 9.3.25 landed
- 2a97a0ad34da 9.6.11 landed
- 1f4a920b7309 12.0 landed