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:33:22
Message-ID: 874leuptnv.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:

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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2018-09-12 16:43:18 Re: Consistent segfault in complex query
Previous Message Andrew Gierth 2018-09-12 16:21:57 Re: Consistent segfault in complex query