From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Curt Sampson <cjs(at)cynic(dot)net> |
Cc: | PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL file location |
Date: | 2002-07-30 05:56:49 |
Message-ID: | 3D462AA1.C1248297@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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".
> What's the advantage of this over just using a symlink?
It is supported by the installation environment, and does not require
the explicit three steps of
1) creating a new directory area
2) moving files to the new area
3) creating a symlink to point to the new area
The default behavior for the patch is exactly what happens now, with the
location plopped into $PGDATA/pg_xlog/
> > 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....
> This I would really love to have.
Yup. These are all pieces of overall resource management for PostgreSQL.
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-07-30 06:00:46 | Re: Proposal: stand-alone composite types |
Previous Message | Joe Conway | 2002-07-30 05:50:41 | Proposal: stand-alone composite types |