Ciprian Popovici discovered an entirely new way to break the safety
interlocks that are meant to prevent you from starting a postmaster
in a data directory of the wrong version:
http://archives.postgresql.org/pgsql-general/2005-06/msg01349.php
While one could say this is pilot error, it's still annoying that
the database manages to hose itself so thoroughly. The problem
as I see it is that we address all data files (including xlog,
pg_control, etc) via absolute path names, and so renaming a
different data directory into place exposes its contents to being
clobbered by the already-running postmaster.
What I am speculating about is:1. At postmaster start (or standalone backend start), chdir into $PGDATA.2.
Henceforth,address everything under $PGDATA by relative paths; don't use DataDir in the path at all.
This way, if someone moves a data directory with a running postmaster
in it, nothing breaks at all. It would probably run a bit faster too,
since file open calls would have fewer directories to traverse through.
The only downside I can see to it is that backend and postmaster crashes
would all consistently dump core into $PGDATA (on platforms where cores
dump into the working directory, which is many but not all). The
current arrangement makes backends dump core into the subdirectory for
the database they are in, which sometimes makes it a bit easier to
identify what's what. But I can't see that that's a valuable enough
property to override the advantages of using relative paths.
Thoughts?
regards, tom lane
