Re: ALTER TABLE name RENAME TO new_name; does not workimmediately

"Alvaro Herrera" <alvherre(at)commandprompt(dot)com> writes:

> Gregory Stark escribió:
>>
>> <megous(at)gmail(dot)com> writes:
>>
>> > Here is a script that is able to reproduce the problem (on my machine
>> > anyway), you may need to play with the number of rows or workmem
>> > settings to be able to reproduce it:
>>
>> Egads, i can confirm that this script reproduces the problem on my machine as
>> well:
>>
>> ALTER TABLE xxx RENAME TO yyy;
>> ALTER TABLE
>> ALTER TABLE yyy RENAME COLUMN col1 TO colA;
>> ERROR: relation "yyy" does not exist
>
> On what version? Sounds like a problem in sinval message processing.

My first suspicion was in the same area. It's two commands within the same
session so it wouldn't actually be receiving any sinval messages just
processing the local list. The two commands are within the same transaction so
only the end-of-command list processed during CommandCounterIncrement() is
happening (or should be happening).

Either a) we're not actually issuing a CommandCounterIncrement() or b) the
command is not being properly marked as non-read-only when the update happens
or, uh, c) something else is broken with generating or executing those
invalidation messages.

> I could not reproduce it here, but didn't try very hard.

Did you try running the script he provided? It happened for me first try.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!