On Thu, Aug 27, 2009 at 12:32 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Attached is a simple patch that uses the environment-variable approach.
> This is a whole lot more self-contained than what would be needed to
> pass the PID as an explicit switch, so I'm inclined to do it this way.
> You could argue that a bad guy could confuse matters by intentionally
> passing an existing postmaster's PID in this variable --- but someone
> with the ability to launch the postmaster can probably also remove an
> existing lockfile, so I don't think there's a credible security risk.
>
> Any objections?

So with this change you would have the startup script not remove the
lock file? Postgres would refuse to start up if there was another
process with the same uid running as long as it wasn't pg_ctl or the
parent of pg_ctl?

This could still fail if the startup script runs some other commands
with & to background them and those commands happen to land with the
pid of postgres? Or the startup script runs pg_ctl within a ( )
subshell?

Or are you suggesting making this change but then still recommending
the startup script you have now. So this would just be to make the
problem less severe for people who use pg_ctl without being aware of
the problem?


-- 
greg
http://mit.edu/~gsstark/resume.pdf

In response to

• Re: We should Axe /contrib/start-scripts at 2009-08-26 23:32:49 from Tom Lane

Responses

• Re: We should Axe /contrib/start-scripts at 2009-08-27 00:01:17 from Tom Lane

pgsql-hackers by date

Next:	From: WANGRUNGVICHAISRI, SHIVESH	Date: 2009-08-26 23:51:55
	Subject: Re: BUG #4996: postgres.exe memory consumption keeps going up
Previous:	From: Kevin Grittner	Date: 2009-08-26 23:40:37
	Subject: Linux LSB init script