Re: initdb change

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: initdb change
Дата
Msg-id 48B2E764.90701@dunslane.net
обсуждение исходный текст
Ответ на Re: initdb change  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: can't stop autovacuum by HUP'ing the server
Следующее
От: David Fetter
Дата:
Сообщение: Re: initdb change