On Mon, Jun 30, 2014 at 5:14 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:
> 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
