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

Re: initdb change

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: David Fetter <david(at)fetter(dot)org>
Cc: 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 17:09:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

David Fetter wrote:
> 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).

This is totally unclear to me.

First, your statement that the directory must not exist is factually 
wrong, according to my inspection of the initdb code.

Second, the whole point of this switch is to allow you to put the xlog 
dir outside the data dir.

Third, there is not the slightest reason I can see for any confusion 
about where it is - initdb creates a symlink in the datadir pointing to 
the real location if you use this option.

Fourth, I utterly fail to see how making for some extra behaviour on 
initdb will save you from confusion at 0300.



In response to

pgsql-hackers by date

Next:From: David FetterDate: 2008-08-25 17:12:03
Subject: Re: initdb change
Previous:From: Dave CramerDate: 2008-08-25 17:07:20
Subject: Re: can't stop autovacuum by HUP'ing the server

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