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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Thomas Lockhart <thomas(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ...
Date: 2002-08-04 17:14:12
Message-ID: 11100.1028481252@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Florian Weimer 2002-08-04 17:53:17 Re: [COMMITTERS] pgsql-server/src include/utils/timestamp.h bac ...
Previous Message Bruce Momjian 2002-08-04 14:21:59 Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c backe ...

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Weimer 2002-08-04 17:53:17 Re: [COMMITTERS] pgsql-server/src include/utils/timestamp.h bac ...
Previous Message Tom Lane 2002-08-04 16:54:56 Re: Did someone break CVS?