Thread

1. Re: Bug #882: Cannot manually log in to database.

   Giles Lean <giles@nemeton.com.au> — 2003-01-25T03:14:59Z

   Tom Lane <tgl@sss.pgh.pa.us> writes:
   > 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.
   
   While UNIX98 (aka the "Single Unix Standard, version 2") talks about a
   "file" argument to utimes() it doesn't make any particular mention
   about restrictions on what type of file, and the function needs to
   work on some non-regular files such as device files to be useful.
   
   > There is already code in the postmaster to touch the socket lock file
   > every few minutes, so as to keep tmp-cleaners from zapping it.  (Or at
   > least there once was; I can't find it right now.)  If we could do the
   > same for the socket file it'd be really nice.  But I didn't think there
   > was any portable way to update the mod timestamp on a socket.
   
   I've done some testing today, and the test passed on everything I
   tested it on:
   
       FreeBSD 4.7-RELEASE alpha
       HP-UX B.11.11 9000/800
       HP-UX B.11.22 ia64
       Linux 2.4.18-14 i686              # RedHat Linux 8.0
       Linux 2.4.18-mckinley-smp ia64    # Debian GNU/Linux 3.0
       NetBSD 1.6_STABLE i386
       OSF1 V4.0 alpha                   # Tru64
       OSF1 V5.1 alpha                   # Tru64
   
   It's too hot here today to go outside but even so, that's enough
   testing ...
   
   I've attached the code I used.  It was considered to work if utimes()
   didn't return an error and if the st_mtime value returned by stat()
   changed:
   
      $ make socket_utimes
      cc -O2   -o socket_utimes socket_utimes.c
      $ ./socket_utimes socket
      utimes() successfully changed a Unix domain socket mtime.
      $ uname -srm
      NetBSD 1.6_STABLE i386
   
   If utimes() works on the other supported platforms that have Unix
   domain sockets perhaps we can put the /tmp cleaners to rest for good.
   
   Anyone willing to test AIX, IRIX, MacOS X, Solaris, or SCO Unix?  I
   don't expect the Windows ports with or without cygwin will support
   Unix domain sockets, so they probably don't need testing. :-)
   
   Regards,
   
   Giles
   
   P.S. http://www.testdrive.hp.com is great for quick portability
   testing.  It was a Compaq program that HP has expanded since their
   merger.  Highly recommended.
   

2. Re: Bug #882: Cannot manually log in to database.

   Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-25T03:35:45Z

   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
   
   

3. Re: Bug #882: Cannot manually log in to database.

   Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-25T05:22:56Z

   Giles Lean <giles@nemeton.com.au> writes:
   > Tom Lane <tgl@sss.pgh.pa.us> 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.
   
   Some digging about on the net revealed that there is a very similar
   function utime() that is POSIX-standard, whereas utimes() is not.
   
   Accordingly, I bit the bullet and put in a configure test to see which
   one(s) we have.  With any luck, this will hold up through 7.4's port
   testing.
   
   			regards, tom lane