Skip site navigation (1) Skip section navigation (2)

Re: WAL file location

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL file location
Date: 2002-07-30 04:08:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Thomas Lockhart <lockhart(at)fourpalms(dot)org> 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.

> 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...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Curt SampsonDate: 2002-07-30 04:13:36
Subject: Re: WAL file location
Previous:From: Bruce MomjianDate: 2002-07-30 03:59:09
Subject: Re: Password sub-process ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group