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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
