On Mon, 2009-12-14 at 18:02 +0000, Greg Stark wrote:
> >> It doesn't seem any more wrong than using hash indexes right after
> >> recovery, crash recovery or otherwise. It's certainly broken, but I
> >> don't see much value in a partial fix. The bottom line is that hash
> >> indexes should be WAL-logged.
> >
> > I know that's your thought; I'm just checking its everyone else's as
> > well. We go to great lengths elsewhere in the patch to avoid queries
> > returning incorrect results and there is a loss of capability as a
> > result. I don't want Hash index users to view this as a feature. I
> don't
> > feel too strongly, but it can be argued both ways, at least.
>
> This goes back to your pluggable rmgr point. Someone could add a new
> index method and get bogus results on their standby. And unlike hash
> indexes where there's some hope of addressing the problem there's
> nothing they can do to fix this.
>
> It does seem like having a flag in the catalog to mark nonrecoverable
> indexes and make them unavailable to query plans on the standby would
> be worth its weight in code.
pg_am.amalmostworks or perhaps pg_am.amhalffinished... :-)
I wouldn't wish to literally persist that situation, especially since if
we had it we couldn't update it during recovery. We need to allow
pluggable indexes in full, not just partially. I think we should extend
pg_am so that rmgr routines can be defined for them also, with dynamic
assignment of rmgrids, recorded in file so we can use them during
recovery.
What we also need is a mechanism to identify and mark indexes as corrupt
while they are being rebuilt, so recovery can complete without them and
then rebuild automatically when recovery finishes. And so they can be
skipped during hot standby.
-- Simon Riggs www.2ndQuadrant.com