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
minute.
> 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 postmaster.pid 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....
-Kevin