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

Here's a little more detail as to how this socket file was getting deleted:

On the system I'm using, if you attempt to start postmaster when an instance
of it is already running, the socket file gets deleted. It was discovered
that upon bootup of the system, the postgres startup script was being
executed twice in the /sbin/rc3.d directory, and this was causing the socket
file to get deleted. It wasn't a cron job.

Ben Kinsey

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, January 24, 2003 11:04 AM
To: Giles Lean
Cc: sk9887(at)sbc(dot)com; benk(at)aiinet(dot)com; pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] Bug #882: Cannot manually log in to database.

Giles Lean <giles(at)nemeton(dot)com(dot)au> writes:
> Either teach your /tmp cleaner not to clean out the socket files as
> Tom Lane suggested, or arrange to update the socket timestamps. I
> think it's easier to just keep updating the timestamps -- then I don't
> have to educate each new system administrator.

> utimes("/tmp/.s.PGSQL.5432", (const struct timeval *) 0);

Hm, do you think that's portable?

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.

regards, tom lane