Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 24F4039D3C5 for ; Sun, 27 Nov 2011 23:30:31 -0400 (AST) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RUrvL-0004Md-BR for pgsql-sql@postgresql.org; Mon, 28 Nov 2011 03:30:31 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pAS3UH0P004628; Sun, 27 Nov 2011 22:30:17 -0500 (EST) To: Belinda Cussen cc: Pavel Stehule , pgsql-sql@postgresql.org Subject: Re: Does anyone know of any issues around ARRAY UNNEST In-reply-to: References: <24013.1322414217@sss.pgh.pa.us> Comments: In-reply-to Belinda Cussen message dated "Mon, 28 Nov 2011 11:15:26 +1100" Date: Sun, 27 Nov 2011 22:30:17 -0500 Message-ID: <4627.1322451017@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -3.1 (---) X-Archive-Number: 201111/84 X-Sequence-Number: 36057 Belinda Cussen 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