Re: initdb mkdir_p() doesn't work - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: initdb mkdir_p() doesn't work
Date
Msg-id 3FC15BED.7020608@dunslane.net
Whole thread Raw
In response to Re: initdb mkdir_p() doesn't work  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Tom Lane wrote:
>>    
>>
>>>AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
>>>fail rather than trying mkdir_p.
>>>      
>>>
>
>  
>
>>Right. In fact, I can't see any good reason to call mkdir and then 
>>mkdir_p at all. See my patch from this afternoon.
>>    
>>
>
>I'm unsure about that.  I liked the original idea of only trying mkdir_p
>when plain mkdir() had failed with ENOENT.  I am not convinced your
>proposed patch will behave desirably under all error cases.  In
>particular, mkdir_p seems rather dependent on knowing just which errno
>codes will get returned --- which is okay for its heritage as BSD-only
>code, but how well will it port?  Better to only invoke it when we have
>reason to think it can help.
>

OK, then the simple thing to do would be either to change the test on 
subdir or to remove it altogether and just check for ENOENT. I'd be 
surprised if the code weren't fairly portable, though.

>
>  
>
>>Sure. Of course, the reason I put this on my web site and asked for 
>>eyeballs was to try to catch some of this sort of stuff before the 
>>program went into the tree :-)
>>    
>>
>
>We have a whole development cycle to shake these issues out.  Don't
>panic.
>
>  
>

<alfred.e.newman-mode>What, me panic?</alfred.e.newman-mode>

I started with 2 goals: have initdb work on Unix with "make check", and 
have the Win32/Cygwin issues sorted out as far as possible, so when we 
get a working w32 postmaster we can actually use it :-). There are 2500 
lines of C here - the odd bug isn't surprising.

cheers

andrew



pgsql-hackers by date:

Previous
From: Philip Yarra
Date:
Subject: Re: Executable files in CVS
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: pg_dump dependency / physical hot backup