Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6 - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Date
Msg-id CAB7nPqSTExy8rf_j7pQN5Zn-SCvFFNA48OKGREyHvNzebpxNew@mail.gmail.com
Whole thread Raw
In response to Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
List pgsql-bugs
On Wed, Nov 2, 2016 at 3:32 PM, Pavel Stehule <pavel.stehule@gmail.com> wro=
te:
> 2016-11-01 22:56 GMT+01:00 Pavel Han=C3=A1k <hanak@is-it.eu>:
>> Can anybody explain what is the problem?
>
> please, can you send test case - I cannot to reproduce this bug on master=
.

I can reproduce the regression on master and 9.6:
DROP TABLE aa;
CREATE TABLE aa (a int, b int, c int);
CREATE OR REPLACE FUNCTION _test_sql_update(in do_update boolean)
    RETURNS VOID LANGUAGE sql VOLATILE AS $$
          update aa
           set a =3D NULL
          where do_update;
    $$;
INSERT INTO aa VALUES (generate_series(1,1,1));
INSERT INTO aa VALUES (generate_series(2,1,1));
INSERT INTO aa VALUES (generate_series(3,1,1));
ALTER TABLE aa DROP COLUMN b;
SELECT _test_sql_update(false);
SELECT _test_sql_update(true);

I am just digging into it... An interesting part is that removing the
WHERE clause makes the regression go away.
--=20
Michael

pgsql-bugs by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6
Next
From: Michael Paquier
Date:
Subject: Re: Problems with "pg.dropped" column after upgrade 9.5 to 9.6