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

"Alvaro Herrera" <alvherre@commandprompt.com> writes:

> Gregory Stark escribi=F3:
>>=20
>> <megous@gmail.com> writes:
>>=20
>> > 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:
>>=20
>> Egads, i can confirm that this script reproduces the problem on my machi=
ne as
>> well:
>>=20
>> 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 happe=
ns
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.


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