On 2014-11-01 13:58:02 -0400, Tom Lane wrote:
> Yeah. When we last discussed this, the difficulty was around how to make
> that combination work. An unlogged index on an unlogged table is no
> problem: the init-fork mechanism is able to make them both go to empty
> after a crash. But for an unlogged index on a logged table, just making
> the index go to empty is not the correct recovery action.
Just removing the relfilenode would probably be better than what we have
today. It sure is pretty unsatisfactory to get a ERROR after a
crash/immediate restart, but it's far better than getting wrong results
back (or even crash).
> We'd been wondering how to make crash recovery change the index's pg_index
> entry into not indisvalid/indisready status. That's hard to do.
It really is hard.
What I've been wondering about whether we should be boring and do it on
backend startup. Roughly similar to the way the relcache init file is
handled. The first backend that starts up for a certain database* scans
pg_index and rechecks all unlogged indexes of logged tables and marks
them as invalid.
* There's a couple ways we could detect that. The most trivial is to
just have a 'initialized' marker file in the database whose presence we
test on startup. That's probably acceptable costwise in comparison to
all the other stuff happening at backend init. We could get more fancy,
but it's probably not needed.
> But
> maybe we don't have to. What about having the init-fork mechanism restore
> a hash index into a state with the metapage marked as invalid? hashinsert
> etc could simply do nothing when they see this metapage state.
> hashgettuple could throw an error saying the index isn't usable until it's
> been REINDEXed.
> This is not quite as nice as an indisvalid-based solution, because it
> requires some extra cooperation from the index AM's code. But setting up
> an init fork requires work from the index AM anyway, so that objection
> doesn't seem terribly strong to me.
The most annoying thing I see with that kind of approach is that we'd
need to read the metapage pretty early during planning. The second most
annoying is that it's harder to for the user to detect which indexes are
in that state - we'd probably need to provide a SQL level function to
detect it.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
