On 2015-08-04 AM 02:57, Peter Geoghegan wrote: > On Mon, Aug 3, 2015 at 8:53 AM, Geoff Winkless <pgsqlad...@geoff.dj> wrote: >> If I create a copy of the table using >> >> CREATE mytab (LIKE brokentab INCLUDING ALL); >> INSERT INTO mytab SELECT * FROM brokentab; > > Also, did you drop any columns from the original "brokentab" table > where the bug can be reproduced? >
This seem to be the case. I could reproduce the reported problem: test=# CREATE TABLE upsert_fail_test(a int, b int, c smallint); CREATE TABLE test=# ALTER TABLE upsert_fail_test DROP c; ALTER TABLE test=# ALTER TABLE upsert_fail_test ADD c smallint; ALTER TABLE test=# ALTER TABLE upsert_fail_test ADD PRIMARY KEY (a, b, c); ALTER TABLE test=# INSERT INTO upsert_fail_test(a, b, c) VALUES (1, 2, 0) ON CONFLICT (a, b, c) DO UPDATE SET c = EXCLUDED.c; INSERT 0 1 test=# INSERT INTO upsert_fail_test(a, b, c) VALUES (1, 2, 0) ON CONFLICT (a, b, c) DO UPDATE SET b = EXCLUDED.b; INSERT 0 1 test=# INSERT INTO upsert_fail_test(a, b, c) VALUES (1, 2, 0) ON CONFLICT (a, b, c) DO UPDATE SET c = EXCLUDED.c; ERROR: attribute 3 has wrong type DETAIL: Table has type integer, but query expects smallint. FWIW, I tried to look why that happens. It seems during set_plan_refs(), fix_join_expr on the splan->onConflictSet targetlist using EXCLUDE pseudo-rel's targetlist as inner targetlist causes columns c's varattno to be changed to 3, whereas in the actual tuple descriptor it's 4 (dropped and added). Eventually, ExecEvalScalarVar() complains when it finds attno 3 is a dropped attribute. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
