Re: [GENERAL] Column rename in an extension update script

From: Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
To: Philippe BEAUDOIN <phb(dot)emaj(at)free(dot)fr>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Column rename in an extension update script
Date: 2017-05-02 19:45:26
Message-ID: 24fbcf75-04d2-9d10-ac12-c99fe4ca96a4@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

moving this thread to -hackers, since this looks like a bug.

On 01/05/2017 08:54, Philippe BEAUDOIN wrote:
> Hi all,
>
> I am coding an update script for an extension. And I am in trouble when
> trying to rename a column of an existing table.
>
> Just after the ALTER TABLE statement, I want to access this table. But
> at this time, the altered column is not visible with its new name.
>

I can reproduce this issue.

It looks like this is due to missing cache invalidation between the
ALTER TABLE execution and next query planning (failure happens during
pg_analyze_and_rewrite()).

AFAICT, CommandCounterIncrement() is responsible for handling
invalidation messages, but in execute_sql_string() this function is
called before executing a Stmt instead of after. Moving the
CommandCounterIncrement() just before the PopActiveSnapshot() call (and
removing the final one) fixes this issue for me, but I have no idea if
this is the right fix.

--
Julien Rouhaud
http://dalibo.com - http://dalibo.org

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Payal Singh 2017-05-02 19:45:46 Implicit typecasting to numeric in psql
Previous Message John R Pierce 2017-05-02 18:55:57 Re: Language support of postgresql

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-05-02 20:40:01 Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)
Previous Message Robert Haas 2017-05-02 19:16:15 Re: Row Level Security UPDATE Confusion