Re: GSoC on WAL-logging hash indexes

On Wed, Apr 30, 2014 at 12:16 PM, Greg Stark <stark(at)mit(dot)edu> wrote:

> I think the key question was if someone wanted to develop a good hash
> index would they start from our current hash index or would they be
> better off starting from a fresh codebase?

If it were me I'd start with the current code. It would be nice if one
could just fork the code to have a new type of index (say "hash2") which is
initially identical, but I never figured out how to do that.

> If the former then we
> should add WAL logging and throw GSOC and other people who ask for
> projects at it. If the latter then we should throw out the current
> codebase and let people develop extensions that add new hash index
> code until someone comes up with a good design we want to move to
> core.
>

Extensions have no hooks into the WAL system, and I'm not optimistic that
that will ever change. Relegating a fundamentally new index to be an
extension virtually *guarantees* that it will never be WAL logged.

>
> 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.
>

+1.

I often lament that unlogged tables cannot be used on a standby or a test
server which were derived from a hot backup. In the case of unlogged
tables, this does mean we would need a way to checkpoint them with a
non-shutdown checkpoint, though. I don't know if that would need a
different type of unlogged table, or a different type of checkpoint.

Cheers,

Jeff