Re: We should Axe /contrib/start-scripts

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Thu, Aug 27, 2009 at 1:01 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Huh? The startup script shouldn't *ever* remove the lock file.
>> That's been true all along, and this doesn't change it.

> I thought that was the whole difference between using pg_ctl to start
> up and the initscripts. Since the init script knows it's starting
> something up at boot time it knows any lock files are left over and
> might contain the pid of one of the other processes the init script
> starts.

An initscript knows no such thing. It's very standard to do, eg,
"service postgresql stop" and "service postgresql start" to restart
a service. If initscripts were coded as you suggest, all it would
take is accidentally reversing the order of those commands to thoroughly
scramble your database.

> I did have another thought. It could compare the time from uptime to
> the timestamp on the lock file. If the server's been restarted since
> the time in the lock file then it must be stale. uhm. unless clock's
> been changed...

Yeah, you can't trust system clocks too much either :-(.

I was actually having second thoughts about the idea of using file
locking. The only environment in which I've heard of file locks not
being trustworthy is NFS, and if you're running a DB on NFS you've
probably got worse problems than this one. Notably, if you mistakenly
try to start postmasters on two different machines against the same
NFS-mounted directory, the PID-based interlock will certainly fail, while
file locking might save you. So maybe we should take another look at
that. Has anyone heard of other contexts in which file locks don't
work? Has Windows got them?

But in the meanwhile, I think this patch is a step forward and won't
break anything that works now.

regards, tom lane