| From: | Noah Misch <noah(at)leadboat(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | REINDEX checking of index constraints |
| Date: | 2013-07-21 17:28:14 |
| Message-ID: | 20130721172814.GC126816@tornado.leadboat.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Historically, REINDEX would always revalidate any uniqueness enforced by the
index. An EDB customer reported that this is not happening, and indeed I
broke it way back in commit 8ceb24568054232696dddc1166a8563bc78c900a.
Specifically, REINDEX TABLE and REINDEX DATABASE no longer revalidate
constraints, but REINDEX INDEX still does so. As a consequence, REINDEX INDEX
is the only form of REINDEX that fixes a failed CREATE INDEX CONCURRENTLY.
Attached patch just restores the old behavior. Would it be worth preserving
the ability to fix an index consistency problem with a REINDEX independent
from related heap consistency problems such as duplicate keys?
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| reindex-constraints-v1.patch | text/plain | 3.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-07-21 18:30:54 | Re: REINDEX checking of index constraints |
| Previous Message | Tom Lane | 2013-07-21 16:40:38 | Re: Preventing tuple-table leakage in plpgsql |