Re: WAL file location - Mailing list pgsql-hackers

> > I've developed patches to be able to specify the location of the WAL
> > directory, with the default location being where it is now. The patches
> > define a new environment variable PGXLOG (a la PGDATA) and postmaster,
> > postgres, initdb and pg_ctl have been taught to recognize a new command
> > line switch "-X" a la "-D".
> Uh ... if I randomly modify PGXLOG and restart the postmaster, what
> happens?  Unless you've added code to *move* pg_xlog, this doesn't seem
> like a good idea.

Perhaps you don't remember the current (and future) behavior of
PostgreSQL. If it does not find the WAL files it declines to start up.
The behavior is very similar to that for the data area. If it does not
exist, the postmaster declines to start.

As noted above, the default behavior remains the same as now. So what is
the objection precisely?

> More generally, I do not like depending on postmaster environment
> variables --- our experience with environment variables for database
> locations has been uniformly bad, and so ISTM that extending that
> mechanism into pg_xlog is exactly the wrong direction to head.

Unsupported allegation. My experience with environment variables for
database locations has been uniformly good (also an unsupported
allegation, but what the heck). And you will note that, as with PGDATA,
the environment variable is not required. So you can easily stay away
from that which you do not like, for whatever reason.

From my experience with other DBMSes, storage management was always a
weak point. You have suggested in the past that hardcoding paths into
the database itself is the Right Way, but in my large Ingres production
systems that was precisely the weak point in their support; you were
hamstrung when planning and expanding storage by choices you made way
back when the the system was first installed.

Linking external definitions to internal logical areas enhances
flexibility, it is not required and does not compromise the system.
Refusing to allow them at all just limits options with no offsetting
benefit.

> The current mechanism for moving pg_xlog around is to create a symlink
> from $PGDATA/pg_xlog to someplace else.  I'd be all in favor of creating
> some code to help automate moving pg_xlog that way, but I don't think
> introducing an environment variable will improve matters.

Your opinion is noted.

> > I'm intending to head towards finer control of locations of tables and
> > indices next by implementing some notion of named storage area, perhaps
> > including the "tablespace" nomenclature though it would not be the same
> > thing as in Oracle since it would not be fixed size but more akin to the
> > "secondary locations" that we support now for entire databases.
> The existing secondary-location mechanism is horrible.  Please do not
> emulate it...

I've not quite understood why you have a strong opinion on something you
don't care about and don't care to contribute to.
                   - Thomas