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

Re: We should Axe /contrib/start-scripts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Chander Ganesan" <chander(at)otg-nc(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: We should Axe /contrib/start-scripts
Date: 2009-08-25 22:03:30
Message-ID: 3111.1251237810@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-08-25 22:31:50
Subject: Re: We should Axe /contrib/start-scripts
Previous:From: Kevin GrittnerDate: 2009-08-25 21:26:11
Subject: Re: We should Axe /contrib/start-scripts

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