On Sunday, October 14, 2012 03:45:49 PM Simon Riggs wrote: > As discussed on other threads, Hash Indexes are currently a broken > feature and bring us into disrepute. > > I describe them as broken because they are neither crash safe, nor > could they properly be called unlogged indexes (or if so, why just > hash?). And also because if somebody suggested implementing them the > way they are now, they would be told they were insane because silent > data corruption is not something we tolerate anymore. We know why they > are like that, but its time to remove the rest of the historical > research legacy. It's hard to say "We respect your data [except if you > press here]" and be taken seriously. > > Suggested actions are > > * Put WARNINGs in the docs against the use of hash indexes, backpatch > to 8.3. CREATE INDEX gives no warning currently, though Index Types > does mention a caution. > > * Mention in the current docs that hash indexes are likely to be > deprecated completely in future releases. Should anybody ever make > them work, we can change that advice quickly but I don't think we're > going to. > > Personally, I would like to see them removed into a contrib module to > allow people to re-add them if they understand the risks. ISTM better > to confiscate all foot-guns before they go off and then re-issue them > to marksmen, at the risk of annoying the people that use them with > full knowledge but that's likely a contentious issue. > > Alternate views?
I vote for at least logging a wal record when a hash index is modified which uses incomplete actions to set 'indisready = false' in case its replayed. That should only use a rather minor amount of code and should help users to find problems faster. Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
