Re: GSoC on WAL-logging hash indexes

* Greg Stark (stark(at)mit(dot)edu) wrote:
> But imnsho doing nothing is a bad idea. We should have long ago either
> added WAL logging or removed the index type. We shouldn't have left a
> foot-gun that large lying around for so long.

I certainly encourage you to work on it. :)

> Incidentally something else I've considered would be having a WAL
> record type saying "relation corrupted" and emitting one the first
> time a hash index is touched after a checkpoint. That could provide a
> general mechanism that might be useful for unlogged operations (and
> might be combinable with the infrastructure for unlogged tables). But
> it seems like a better tool for other objects than hash indexes.

Ugh, please do not make unlogged tables suffer for this. I feel it is
*quite* clear when you say "UNLOGGED" or "TEMP" in the CREATE statement
that you know what you're gonna get. Perhaps we should require
'UNLOGGED INDEX' to be passed in when someone creates a 'hash' index
instead.

> Another quick fix would be having a GUC allow_unrecoverable_relations
> which defaulted to false. Creating a hash index (and presumably
> unlogged tables) would error out with a hint to set that to true so at
> least users who create them would have to know what they were in for.

-1

> Right now we're seeing a lot of users who create hash indexes and then
> complain about corrupted standbys.

Uh, we are? If you're saying that $employer is, great, but please
clarify that as the rest of us aren't 'in the loop' as far as that goes
and we see the various list/IRC traffic instead, and I can't remember
ever seeing such a complaint in either place (but I'll admit, my memory
isn't the best).

> I could do the legwork on either the GUC or moving hash indexes to an
> extension if there's a consensus. But I suspect either will be quite
> controversial...

-1 on the GUC. I'd be alright with finding a way to make it clear, upon
creation of the hash index, that it's not WAL'd (maybe even just throw a
WARNING, it'd be better than nothing..). Trying to rip out the current
hash index wouldn't be great, imv. If you'd like to build an extension
which provides hash indexes- I say go for it? Nothing stopping you as
far as that's concerned.

Thanks,

Stephen