Thanks! On 28 November 2011 14:30, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Belinda Cussen <belinda.cus...@servian.com.au> writes: > > I've managed to produce this fault consistently now. > > Below is the simplified code: > > > CREATE TABLE foo_1 (id int primary key,media_uri TEXT); > > INSERT INTO foo_1(id) SELECT i FROM generate_series(1,1000000) g(i); > > > CREATE OR REPLACE FUNCTION bb_crash_db_5 () RETURNS TEXT AS $$ > > DECLARE > > v_activity_id_list INTEGER ARRAY; > > BEGIN > > > SELECT ARRAY(SELECT id FROM foo_1 ORDER BY id LIMIT 100000) INTO > > v_activity_id_list; > > UPDATE foo_1 > > SET media_uri = 'a' > > WHERE id IN (SELECT activity_id FROM UNNEST (v_activity_id_list) > > activity_id) > > ; > > return 'success'; > > > END; > > $$ LANGUAGE plpgsql; > > > I then open 2 command lines and run: > > select bb_crash_db_5(); > > Thanks, I was able to reproduce it with this test case. It turns out > not to have anything directly to do with UNNEST, but with the code that > deals with concurrent row updates. > > I've committed a fix, which will appear in next week's updates. > Thanks for the report and test case! > > regards, tom lane > -- [image: Servian Logo]*Belinda Cussen* | Servian Pty Ltd<http://www.servian.com.au/> | *m:* 0466 309 169 | *t:* 02 9376 0700 | f*:* 02 9376 0730
