Re: Strange issue with initdb on 8.0 and Solaris automounts

From: "David Parker" <dparker(at)tazznetworks(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kenneth Lareau" <elessar(at)numenor(dot)org>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Strange issue with initdb on 8.0 and Solaris automounts
Date: 2005-01-28 02:40:25
Message-ID: 07FDEE0ED7455A48AC42AC2070EDFF7C3EDFA5@corpsrv2.tazznetworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Will this make it into 8.1?

>-----Original Message-----
>From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>Sent: Thursday, January 27, 2005 7:38 PM
>To: Kenneth Lareau
>Cc: David Parker; pgsql-hackers(at)postgresql(dot)org
>Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and
>Solaris automounts
>
>Kenneth Lareau <elessar(at)numenor(dot)org> writes:
>> In message <22095(dot)1106869848(at)sss(dot)pgh(dot)pa(dot)us>, Tom Lane writes:
>>> Could you truss that and see what it does?
>
>> Here's the relevant truss output from 'mkdir
>/software/postgresql-8.0.0'
>> on my Solaris 9 system:
>
>> 10832: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS
>> 10832: stat64("/software/postgresql-8.0.0", 0xFFBFFA38) = 0
>
>> It's doing the stat after the mkdir attempt it seems, and
>coming back
>> with the correct response. Hmm, maybe I should look at the
>Solaris 8
>> code for the mkdir command...
>
>Well, the important point is that the stat does succeed. I'm
>not going to put in anything as specific as a check for
>ENOSYS, but it seems reasonable to try the stat first and
>mkdir only if stat fails.
>I've applied the attached patch.
>
> regards, tom lane
>
>*** src/bin/initdb/initdb.c.orig Sat Jan 8 17:51:12 2005
>--- src/bin/initdb/initdb.c Thu Jan 27 19:23:49 2005
>***************
>*** 476,481 ****
>--- 476,484 ----
> * this tries to build all the elements of a path to a
>directory a la mkdir -p
> * we assume the path is in canonical form, i.e. uses / as
>the separator
> * we also assume it isn't null.
>+ *
>+ * note that on failure, the path arg has been modified to show the
>+ particular
>+ * directory level we had problems with.
> */
> static int
> mkdir_p(char *path, mode_t omode)
>***************
>*** 544,573 ****
> }
> if (last)
> (void) umask(oumask);
>! if (mkdir(path, last ? omode : S_IRWXU |
>S_IRWXG | S_IRWXO) < 0)
> {
>! if (errno == EEXIST || errno == EISDIR)
>! {
>! if (stat(path, &sb) < 0)
>! {
>! retval = 1;
>! break;
>! }
>! else if (!S_ISDIR(sb.st_mode))
>! {
>! if (last)
>! errno = EEXIST;
>! else
>! errno = ENOTDIR;
>! retval = 1;
>! break;
>! }
>! }
>! else
> {
> retval = 1;
> break;
> }
> }
> if (!last)
> *p = '/';
>--- 547,570 ----
> }
> if (last)
> (void) umask(oumask);
>!
>! /* check for pre-existing directory; ok if it's
>a parent */
>! if (stat(path, &sb) == 0)
> {
>! if (!S_ISDIR(sb.st_mode))
> {
>+ if (last)
>+ errno = EEXIST;
>+ else
>+ errno = ENOTDIR;
> retval = 1;
> break;
> }
>+ }
>+ else if (mkdir(path, last ? omode : S_IRWXU |
>S_IRWXG | S_IRWXO) < 0)
>+ {
>+ retval = 1;
>+ break;
> }
> if (!last)
> *p = '/';
>

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2005-01-28 06:48:44 Re: Continue transactions after errors in psql
Previous Message Marc G. Fournier 2005-01-28 02:29:39 Re: Patent issues and 8.1