From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Giles Lean <giles(at)nemeton(dot)com(dot)au> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug #882: Cannot manually log in to database. |
Date: | 2003-01-25 03:35:45 |
Message-ID: | 1487.1043465745@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Giles Lean <giles(at)nemeton(dot)com(dot)au> writes:
>>> utimes("/tmp/.s.PGSQL.5432", (const struct timeval *) 0);
>>
>> Hm, do you think that's portable?
> Hm ... yes, actually I do. I use it on HP-UX, and testing indicates
> that it works on FreeBSD, Linux, NetBSD and Tru64 as well.
> Thinking about it, a Unix domain socket has an entry in the filesystem
> and thus an inode. utimes() operates on the inode so it makes sense to
> me that this should Just Work.
Sure, the question was more about whether the system call exists
everywhere.
> I've done some testing today, and the test passed on everything I
> tested it on:
I can add HPUX 10.20, Mac OS X 10.2.3, and a pretty ancient Linux
(kernel 2.0.36, not sure of the exact distro) to the list of stuff
your test program seems to pass on.
> If utimes() works on the other supported platforms that have Unix
> domain sockets perhaps we can put the /tmp cleaners to rest for good.
My feeling is we may as well put it in. If it turns out we have
platforms without utimes(), we can put in a configure test and #ifdef
it. If the call doesn't exist or doesn't update the mod time as
expected, we're no worse off than before --- and for platforms where
it does work, this is a big win.
Thanks for looking into it! I'll work on applying the fix.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-25 05:22:56 | Re: Bug #882: Cannot manually log in to database. |
Previous Message | Giles Lean | 2003-01-25 03:14:59 | Re: Bug #882: Cannot manually log in to database. |