"Marc G. Fournier" <scrappy@hub.org> writes:
>> I think Tom is on to something here. I meant to ask but never got
>> around to it. Why would anyone need to move the XLOG after you've
>> inited the db?
> I just determined that disk I/O is terrible, so want to move the XLOG over
> to a different file system that is currently totally idle ...
Sure, needing to manually move the xlog directory is a plausible thing,
but *you can already do it*. The current procedure is
1. shut down postmaster
2. cp -p -r xlog directory to new location
3. rm -rf old xlog directory
4. ln -s new xlog directory to $PGDATA/xlog
5. start postmaster
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.
regards, tom lane