Re: [COMMITTERS] pgsql-server/src - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql-server/src
Date
Msg-id 25368.1029247219@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql-server/src  (Oliver Elphick <olly@lfix.co.uk>)
Responses Re: [COMMITTERS] pgsql-server/src  (Oliver Elphick <olly@lfix.co.uk>)
List pgsql-hackers
Oliver Elphick <olly@lfix.co.uk> writes:
> Could you not store the location of the xlog directory as an entry in
> $PGDATA/global/pg_control?

We could do that *only* if we were to produce an xlog-moving program
immediately; otherwise we've regressed in functionality compared to
prior releases.

I do not think it's necessary to be quite that anal about tying the two
directories together --- the manual symlinking procedure I described has
been around for two releases now, and while doubtless not that many
people have actually done it, we've not heard any reports of failures.
The thing is that if the DBA has to do this himself, he is very well
aware that he's performing a critical procedure, and he's not likely
to muck it up.

I think that from a safety point of view either a symlink or a
config-file entry are perfectly acceptable, and in general I prefer
plain-text config files to those which are not.  (Right now, pg_control
is *not* a config file: there is not anything in it that you might want
to edit in normal system maintenance.  It should stay that way.)

Marc's idea of matching signature files would be a better
safety-checking mechanism than just making the data directory's xlog
link hard to get at.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: OOP real life example (was Re: Why is MySQL more
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke