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
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 |
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 |