On Sun, Aug 26, 2012 at 10:25 AM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
> PID 8574 is actually iTunes, not PG,
iTunes? What is that doing running under PG's userid?
We back our client application with PG, each OSX user gets their own instance of PG.
It runs as that OSX user.
> Seb figured out how to contrive this situation.
> Run PG, copy the pid file, stop pg, copy the copied pid file back to the
> data dir and edit it, replacing the old PID with that of another running
> process.
You're kidding, right? If you intentionally set out to break the
postmaster interlock, you will doubtless be able to do that, and would
still be able to break any other algorithm we might devise. Let's
confine this discussion to scenarios that could arise without
intentional interference.
We were presented with a problem we didn't understand.
We set out to try and figure out how we could replicate the problem, for debugging purposes.
We managed to do so to see how our application behaves, and to see how PG behaves.
In the wild this scenario has arisen without intentional interference. In debugging, yes, we contrived the situation to replicate the behaviour. Mind you, we may be using PG in an environment that isn't advisable.
We just started this discussion to learn and understand, and to see if this is a situation that would be expected to be handled.
Thanks,
Michael.
