| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Keith Fiske <keith(at)omniti(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Index corruption with CREATE INDEX CONCURRENTLY |
| Date: | 2017-02-17 17:45:51 |
| Message-ID: | 30991.1487353551@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> However, you might be able to find it without so much random I/O.
> I'm envisioning a seqscan over the table, in which you simply look for
> HOT chains in which the indexed columns aren't all the same. When you
> find one, you'd have to do a pretty expensive index lookup to confirm
> whether things are OK or not, but hopefully that'd be rare enough to not
> be a big performance sink.
Ah, nah, scratch that. If any post-index-build pruning had occurred on a
page, the evidence would be gone --- the non-matching older tuples would
be removed and what remained would look consistent. But it wouldn't
match the index. You might be able to find problems if you were willing
to do the expensive check on *every* HOT chain, but that seems none too
practical.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Christensen | 2017-02-17 17:53:39 | Re: [PATCH] Add pg_disable_checksums() and supporting infrastructure |
| Previous Message | David E. Wheeler | 2017-02-17 17:45:00 | Re: removing tsearch2 |