Tom Lane wrote: > Thomas Lockhart <[EMAIL PROTECTED]> writes: > > 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. > > 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. > > 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.
100% agree. > > 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... 200% agree. ;-) -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
