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

From Oliver Elphick
Subject Re: [COMMITTERS] pgsql-server/src
Date
Msg-id 1029246591.1353.579.camel@linda
Whole thread Raw
In response to Re: [COMMITTERS] pgsql-server/src  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql-server/src  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2002-08-13 at 14:15, Tom Lane wrote:
> 4. ln -s new xlog directory to $PGDATA/xlog
> With the patch it's almost the same, but you can instead of (4) substitute
> 
> (4a) Change PGXLOG environment variable or -X argument in start script.
> 
> That is *not* materially easier than an "ln" in my book.  And it's
> fraught with all the risks we've come to know and not love over the
> years: it's just way too easy to start a postmaster with the wrong set
> of environment variables.  (Hand start vs start from boot script, etc,
> etc, etc.)  But this time the penalty for getting it wrong is, very
> possibly, irrecoverable corruption of your database.
> 
> I see a serious downside to doing it this way, and not enough upside
> to justify taking the risk.  We should continue to keep the "where's the
> xlog" information in the database directory itself.  While a symlink
> isn't the only possible way to do that (a configuration-file item might
> do instead), I just don't think it's a good idea to allow it to be
> specified externally.

Since the xlog is so closely linked with the database, I would be
unhappy for its location to be determined by a parameter in a file that
could be edited by an ignorant or careless administrator.  Thomas does
not like symlinks.  Equally I don't like the idea of an environment
variable, which is even more vulnerable to misuse.

Could you not store the location of the xlog directory as an entry in
$PGDATA/global/pg_control?   The xlog is as closely tied in with the
database as is its locale, which is already stored in pg_control.

To let the directory be moved, there should then be a standalone program
that would shut down the server, copy the xlog directory to the new
location and set its access permissions; on a successful copy, change
the control entry, delete the old xlog directory and finally restart the
server.  Use of such a program would protect against other possible
errors, such as pointing two different databases to the same xlog.

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight, UK                            
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
========================================   "Watch ye therefore, and pray always, that ye may be      accounted worthy
toescape all these things that shall     come to pass, and to stand before the Son of man."
    Luke 21:36 
 



pgsql-hackers by date:

Previous
From: Don Baccus
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