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

Can I propose a compromise? Thomas, can we have only initdb honor
PGXLOG, just like it honors PGDATA? That way, admins can set PGXLOG and
initdb will take care of the symlinking for them, and we don't have to
push PGXLOG/-X down into all the other server parts. How do people like
that?

As far as tablespaces, we have three ways of storing directory path
info: environment variables, in the database, or in symlinks. If we
choose the first or last options, XLOG will have to follow that plan.
If we choose database, well there is no database during initdb so XLOG
would have a different system of specifying the location. I think
having only initdb honor PGXLOG and using a symlink will give us maximum
flexibility when we decide on table spaces.

Actually, as I remember, there was a strong vote that tablespaces where
going to use symlinks for storage, at least in some way.

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

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