Belinda Cussen <belinda.cussen@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
