Horton

Re: Index corruption with CREATE INDEX CONCURRENTLY

Jim Nasby <jim.nasby@bluetreble.com>

View thread View on postgr.es
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Robert Haas <robertmhaas@gmail.com>, Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, Keith Fiske <keith@omniti.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-23T20:51:48Z
Lists: pgsql-hackers 
On 2/19/17 5:27 AM, Robert Haas wrote:
> (1) a multi-batch hash join, (2) a nested loop,
> and (3) a merge join.  (2) is easy to implement but will generate a
> ton of random I/O if the table is not resident in RAM.  (3) is most
> suitable for very large tables but takes more work to code, and is
> also likely to be a lot slower for small tables than a hash or
> nestloop-based approach.

As I understand it, #3 is already in place for validate_index(). I think 
you'd just need a different callback that checks the heap key.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

Commits

  1. Avoid returning stale attribute bitmaps in RelationGetIndexAttrBitmap().