Re: We should Axe /contrib/start-scripts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: We should Axe /contrib/start-scripts
Date
Msg-id 3111.1251237810@sss.pgh.pa.us
Whole thread Raw
In response to Re: We should Axe /contrib/start-scripts  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: We should Axe /contrib/start-scripts  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: We should Axe /contrib/start-scripts  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
>> stuff like vacuum scripts could surely be run from a different
>> userid.
> My first thought was "they have to run as the database superuser." 
> (In our case, that is the same as the OS user running the cluster.)
> But that's wrong, of course.  They have to run as *a* database
> superuser.  We could fix that.

Well, the database userid needn't be the same as the OS userid.
Even if you're using ident auth, you could provide an identmap
to allow the vacuum-user to log in as the database superuser.

> Still, this seems like it's not as deterministic as it should be.  Is
> there any reasonable way to pin it down beyond the PID?  Like also
> saving a start time into the postmaster.pid file and checking that it
> maches the start time of the PID found?

How would you get the latter in a portable fashion?  (Do not mention
ps please ... and I don't want to hear about lsof either ...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: We should Axe /contrib/start-scripts
Next
From: "Kevin Grittner"
Date:
Subject: Re: We should Axe /contrib/start-scripts