Re: Backend working directories and absolute file paths - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Backend working directories and absolute file paths
Date
Msg-id 19395.1120146179@sss.pgh.pa.us
Whole thread Raw
In response to Re: Backend working directories and absolute file paths  (David Fetter <david@fetter.org>)
Responses Re: Backend working directories and absolute file paths
List pgsql-hackers
David Fetter <david@fetter.org> writes:
> On Thu, Jun 30, 2005 at 10:55:58AM -0400, Tom Lane wrote:
>> 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.

> There will always be a way for a user with enough knowlege to hose a
> database completely.  I think it's significant that Mr. Popovici is
> the first to manage this one, in the sense that it takes an especially
> creative combination of a little knowlege and rushing in where angels
> fear to tread to reproduce the problem.  There will never be a
> solution to human foolishness, so I say we just tell him and others
> like him to restore from backup and move on.

Well, I'm not sure that he's the first to manage it --- he's just the
first to report it in an identifiable way (which is the usual criterion
for assigning credit for discoveries ;-)).

Renaming data directories around is not that uncommon, especially if
you're using a platform that really really wants the active database to
be /var/lib/pgsql/data (if you're running Red Hat's current selinux
policy, you don't have a whole lotta choice about that).  All you have
to do is rename and shut down the postmaster in the wrong order, and
you're hosed.  (The terminating checkpoint will be able to write some
files and not others, depending on what it already had open, so I think
this could be a recipe for corrupting the moved-away database as well as
the moved-in one :-()

Do you have a specific objection to switching over to relative paths,
or are you just saying that this one report doesn't excite you enough
to change it?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] Users/Groups -> Roles
Next
From: Stephen Frost
Date:
Subject: Re: [PATCHES] Users/Groups -> Roles