Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately
От | Gregory Stark |
---|---|
Тема | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately |
Дата | |
Msg-id | 87ljz4d8dc.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately
|
Список | pgsql-bugs |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Also, I can still reproduce it with just REINDEX TABLE pg_class instead > of REINDEX DATABASE. Ah, I had tried just a reindex xxx but not a reindex pg_class. * reindex_index will attempt to update the pg_class rows for the relation * and index. If we are processing pg_class itself, we want to make sure * that the updates do not try to insert index entries into indexes we * have not processed yet. (When we are trying to recover from corrupted * indexes, that could easily cause a crash.) We can accomplish this * because CatalogUpdateIndexes will use the relcache's index list to know * which indexes to update. We just force the index list to be only the * stuff we've processed. Uhm. Is it possible we're mistakenly doing a HOT update because we're lying about what indexes exist? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
В списке pgsql-bugs по дате отправления: