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

Re: initdb change

From: Joshua Drake <jd(at)commandprompt(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: initdb change
Date: 2008-08-25 18:05:21
Message-ID: 20080825110521.7e9cef31@jd-laptop (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, 25 Aug 2008 13:56:16 -0400
Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> >
> > That is what I was suggesting.
> >
> Why should the xlog directory be treated specially?

Consider the following:

mount /dev/sda1 /var/lib/pgsql
mount /dev/sdb1 /srv1/pgsql/pg_xlog (which has a link
from /var/lib/pgsql/data/pg_xlog)

initdb -D /var/lib/pgsql/data -X /var/lib/pgsql/data/pg_xlog

Will fail; now you have multiple steps to get everything where it
should be.

> We don't do this
> for any other subdirectory of PGDATA. The extra logic would be a

Well the only other directory it would even matter for would be pg_clog
(maybe). I grant that it is a very little feature that could be lived

> nuisance and for no great gain in functionality that I can see.

In an environment where you are provisioning many spindle machines over
many differently mounts and raid configurations it could be useful. The
question is; is it worth it? I don't know. I was just trying to
understand exactly what David was talking about and offer some

> This whole discussion springs from a misconception apparently, so
> let's just move on.

Well that pretty much describes life doesn't it? :)


Joshua D. Drake

The PostgreSQL Company since 1997: 
PostgreSQL Community Conference:
United States PostgreSQL Association:
Donate to the PostgreSQL Project:

In response to


pgsql-hackers by date

Next:From: Steve AtkinsDate: 2008-08-25 18:43:48
Subject: Re: Proposal: new border setting in psql
Previous:From: Andrew DunstanDate: 2008-08-25 17:56:16
Subject: Re: initdb change

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