Re: initdb change - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: initdb change
Date
Msg-id 48B2E764.90701@dunslane.net
Whole thread Raw
In response to Re: initdb change  (David Fetter <david@fetter.org>)
List pgsql-hackers

David Fetter wrote:
> On Mon, Aug 25, 2008 at 11:48:29AM -0400, Tom Lane wrote:
>   
>> David Fetter <david@fetter.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.

cheers

andrew


pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: can't stop autovacuum by HUP'ing the server
Next
From: David Fetter
Date:
Subject: Re: initdb change