Re: ALTER TABLE name RENAME TO new_name; does not workimmediately
От | Gregory Stark |
---|---|
Тема | Re: ALTER TABLE name RENAME TO new_name; does not workimmediately |
Дата | |
Msg-id | 87y735d2rc.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE name RENAME TO new_name; does not work immediately (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: ALTER TABLE name RENAME TO new_name; does not
workimmediately
|
Список | pgsql-bugs |
"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!
В списке pgsql-bugs по дате отправления: