From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] initdb mkdir_p() doesn't work |
Date: | 2003-11-30 05:07:44 |
Message-ID: | 200311300507.hAU57iL06130@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
>
> >
> >
> > Peter Eisentraut wrote:
> >
> >> Here is what I get:
> >>
> >> peter ~$ pg-install/bin/initdb pg-install/var/data
> >> ...
> >> creating directory pg-install/var/data ... initdb: failed
> >>
> >> No points for details in the error message here either.
> >>
> >> If I create pg-install/var first, then it work.
> >>
> >
> > I will check it out. I know I spent quite some time making sure this
> > worked, but I might have missed something obvious. I wonder if it is
> > platform specific?
> >
> >
>
> I don't remember why the code is the way it is. The failure appears to
> be before we ever get to mkdir_p(). I can't see any reason right now why
> we can't call mkdir_p() in all cases. The attached patch does that (and
> makes the code slightly simpler as a result). I tested it with one
> element and 2 element existant and nonexistant paths, and it appeared to
> work for all of them.
>
> cheers
>
> andrew
>
> ? .deps
> ? initdb
> Index: initdb.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/initdb.c,v
> retrieving revision 1.11
> diff -c -w -r1.11 initdb.c
> *** initdb.c 17 Nov 2003 20:35:28 -0000 1.11
> --- initdb.c 23 Nov 2003 19:46:56 -0000
> ***************
> *** 797,803 ****
> mkdatadir(char *subdir)
> {
> char *path;
> - int res;
>
> path = xmalloc(strlen(pg_data) + 2 +
> (subdir == NULL ? 0 : strlen(subdir)));
> --- 797,802 ----
> ***************
> *** 807,819 ****
> else
> strcpy(path, pg_data);
>
> ! res = mkdir(path, 0700);
> ! if (res == 0)
> ! return true;
> ! else if (subdir == NULL || errno != ENOENT)
> ! return false;
> ! else
> ! return !mkdir_p(path, 0700);
> }
>
>
> --- 806,812 ----
> else
> strcpy(path, pg_data);
>
> ! return (mkdir_p(path, 0700) == 0);
> }
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-11-30 06:12:54 | Patch queue |
Previous Message | Bruce Momjian | 2003-11-30 05:07:34 | Re: initdb mkdir_p() doesn't work |
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-11-30 05:08:53 | export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question) |
Previous Message | Bruce Momjian | 2003-11-30 05:07:34 | Re: initdb mkdir_p() doesn't work |