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

Re: initdb change

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: initdb change
Date: 2008-08-25 16:04:01
Message-ID: 20080825160401.GT32546@fetter.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Aug 25, 2008 at 11:48:29AM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > While initdb allows you to choose a directory for transaction
> > logs, it can't already exist, so it can't be in its usual place
> > under $PGDATA.  I'd like to propose that this be allowed by having
> > an alternate syntax for the -X option, namely, "existing."
> 
> > When -X is set to "existing", it would check whether pg_xlog is a
> > directory and the only thing in $PGDATA.  One way to do that is to
> > add a new return code to check_data_dir() and a new branch of the
> > case statement after it's called.
> 
> Why is this useful?  It seems like just extra complication.

Letting people put a separate I/O channel in for pg_xlog in the usual
spot at initdb time makes it easier on everybody.  The person tasked
with solving a problem is not left blearily wondering where pg_xlog
went when their phone rings at 0300, as such phones are wont to do. :)

Another approach to this is to look by default for pg_xlog in the
$PGDATA-to-be, testing it for all the appropriate properties
(directory-ness, permissions, emptiness).

Cheers,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

pgsql-hackers by date

Next:From: Joshua DrakeDate: 2008-08-25 16:29:03
Subject: Re: initdb change
Previous:From: Joshua DrakeDate: 2008-08-25 15:51:26
Subject: Re: initdb change

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