Skip site navigation (1) Skip section navigation (2)

Re: We should Axe /contrib/start-scripts

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Chander Ganesan <chander(at)otg-nc(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We should Axe /contrib/start-scripts
Date: 2009-08-27 00:27:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Aug 27, 2009 at 1:01 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So with this change you would have the startup script not remove the
>> lock file?
> 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

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...


In response to


pgsql-hackers by date

Next:From: Craig RingerDate: 2009-08-27 00:35:54
Subject: Re: BUG #4996: postgres.exe memory consumption keeps going up
Previous:From: Tom LaneDate: 2009-08-27 00:24:00
Subject: Re: MySQL Compatibility WAS: 8.5 release timetable, again

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group