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

Re: We should Axe /contrib/start-scripts

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 21:26:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote: 
> Only if they are running at times when your postmaster(s) aren't ...
Well, those rsync scripts for pushing the PITR base backup and the WAL
stream to other machines are crontab jobs which kick off once per
> Still, just from a security point of view, it might be better if
> those don't run as the postgres operating-system user.  Not sure if
> that's workable for rsync (since it has to be able to read the
> postgres files)
We have some things running as that user which wouldn't have to be. 
You're right; we should change that.  I don't see any way around it
for generating the PITR base backup on the machine, though.
> 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.
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 file and checking that it
maches the start time of the PID found?  Or, as I suggested before,
checking that the potentially conflicting PID has some file open which
would always be open if it was indeed a previous postmaster?  It seems
like there ought to be some way to get better traction on this....

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-08-25 22:03:30
Subject: Re: We should Axe /contrib/start-scripts
Previous:From: Andrew DunstanDate: 2009-08-25 21:23:17
Subject: Re: We should Axe /contrib/start-scripts

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