Re: Bug #882: Cannot manually log in to database.
От | Tom Lane |
---|---|
Тема | Re: Bug #882: Cannot manually log in to database. |
Дата | |
Msg-id | 1487.1043465745@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bug #882: Cannot manually log in to database. (Giles Lean <giles@nemeton.com.au>) |
Список | pgsql-bugs |
Giles Lean <giles@nemeton.com.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
В списке pgsql-bugs по дате отправления: