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: 48B2E764.90701@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

cheers

andrew

In response to

Browse pgsql-hackers by date

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