| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| 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:03:34 |
| Message-ID: | 23406.1218391414@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
I wrote:
> What I suspect is we've broken the logic that manages REINDEX applied to
> pg_class itself.
Hm, this is a HOT bug. (Unless the OP found it on something older
than 8.3, in which case we might have more than one issue involved.)
What I'm seeing is that when heap_update checks to see if the new
pg_class tuple is HOT-updatable, RelationGetIndexAttrBitmap tells it
that only the OID is an indexed attribute, and so it does a HOT update,
leaving the wrong index entry in place.
Apparently, rd_indexattr needs to get cleared someplace where it
isn't being cleared right now. I'm sure this is related to the
fancy dance we do for pg_class reindexing, but not sure yet where
to fix it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-08-10 18:37:19 | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately |
| Previous Message | Tom Lane | 2008-08-10 17:28:56 | Re: ALTER TABLE name RENAME TO new_name; does notworkimmediately |