Right now PostgreSQL appears to rely on the absence of the tablespace directory as a flag to tell it "don't start up, something's badly wrong here".
Well, in fact the behavior is just to give a LOG message:
LOG: could not open tablespace directory "pg_tblspc/100607/PG_9.3_201306121": No such file or directory
But it starts fine. No?
I ask because I'm relying on that. My patch does not on startup, so in the absence of the tablespace directory, the above LOG is shown even for "temporary-tablespace", and it tries to create the directory when any process tries to use it. As we don't have catalog access on startup, it will require me to use some kind of _init fork for tablespace if we want it to be re-created during startup. Should we bother about this?
If the user creates the tablespace directory, it figures they at least know what they're doing and carries on starting up with the empty tablespace. It's treated as an admin statement - "I know it's gone, it's not coming back, just carry on as best you can".
Well, I think for a tablespace like that it is okay to create it on-demand (note that I have done this only for "temp", not ordinary ones).
If Pg were to auto-create the directory, then if (say) a mount of a tablespace dir failed at boot, Pg would still happily start up and might create files in the tablespace, despite there being inaccessible tables/indexes/etc on the not-mounted volume that's *supposed* to be the tablespace storage. That'd create plenty of mess.
So no, I don't think Pg should auto-create the tablespace directory if it's missing for non-temporary tablespaces.
Ok. I agree. Let's create only for temporary ones (as done by the patch now).
Not unless the current (less than friendly) behaviour around lost tablespaces is replaced with something like an `ignore_missing_tablespaces` or `drop_missing_tablespaces` GUC - akin to our existing `zero_missing_pages` recovery GUC.
You meant `zero_damaged_pages`, I think. I don't think that is really necessary in this case.
Anyway, I was thinking about some way to this tablespace to also allow creation of non-temporary indexes, and after a crash we could mark such indexes as `NOT VALID` (perhaps `zero_damaged_pages` could be of help here?!). That should be part of another patch thought, and would require more thoughts. But I think that would be a great improvement for some environments, like those on AWS with their ephemeral SSDs.
Regards,
-- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
