Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ...
Date
Msg-id 11100.1028481252@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Thomas Lockhart wrote:
>> Implement WAL log location control using "-X" or PGXLOG.

> Woh, I didn't think we had agreement on this.  This populates the 'X'
> all over the system (postgres, postmaster, initdb, pg_ctl),  while the
> simple solution would be to add the flag only to initdb and use a
> symlink from /data.  I also think it is less error-prone because you
> can't accidentally point to the wrong XLOG directory.  In fact, you
> almost have to use an environment variable unles you plan to specify -X
> for all the commands.   In my mind, PGDATA should take care of the whole
> thing for pointing to your data.

> If you want to do it this way, I request a vote.

I have to vote a strong NO on this.  What the patch essentially does is
to decouple specification of the data directory ($PGDATA or -D) from the
xlog directory ($PGXLOG or -X).  This might seem nice and clean and
symmetrical, but in fact it has no conceivable use except for shooting
yourself in the foot in a particularly nasty manner.  The xlog *cannot*
be decoupled from the data directory --- there are pointers in
pg_control and in every single data page that depend on the state of
xlog.  Trying to make them look independent is just a recipe for
breaking your database by starting the postmaster with the wrong
combination of PGDATA and PGXLOG.  And I'm not at all sure it'll be
possible to recover after you do that: if the postmaster notices the
discrepancy, it is likely to try to fix it by rolling forward from the
last checkpoint it can find in the mismatching xlog.  Oops :-(

I think the existing mechanism of using a symlink in the data directory
when you want to move xlog is far safer and more reliable.  I do not see
what functionality is added by this patch that can possibly justify the
hazards it creates.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Did someone break CVS?
Next
From: Florian Weimer
Date:
Subject: Re: [COMMITTERS] pgsql-server/src include/utils/timestamp.h bac ...