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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.c
Date: 2002-08-07 02:39:25
Message-ID: 200208070239.g772dPK25449@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers


Thomas, have you commented on the objections to this patch? If so, I
didn't see it.

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Lockhart 2002-08-07 14:30:25 Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Previous Message Peter Eisentraut - PostgreSQL 2002-08-06 21:13:44 pgsql-server/src/bin/psql sv.po

Browse pgsql-hackers by date

  From Date Subject
Next Message Curt Sampson 2002-08-07 02:41:54 Re: Why is MySQL more chosen over PostgreSQL?
Previous Message Curt Sampson 2002-08-07 02:31:32 Re: CLUSTER and indisclustered