From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, <megous(at)gmail(dot)com>, <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately |
Date: | 2008-08-10 18:37:19 |
Message-ID: | 87ljz4d8dc.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-08-10 18:50:59 | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately |
Previous Message | Tom Lane | 2008-08-10 18:03:34 | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately |