On 26 Aug 2012, at 17:21, Michael Clark wrote: > On Sun, Aug 26, 2012 at 10:25 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Michael Clark <codingninja@xxxxxxxxx> writes: >> > 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. Are you certain that's necessary? It's generally a better idea to run a single PG server with a database for each user. Having multiple copies running has its use-cases, but the necessity is quite uncommon. You could compare what you're doing to giving every user their own copy of OS X. There are situations in which you'd want that, but generally its considered a bad idea. You'd never have even thought to do that if you were, for example, using Oracle for the database. That's a hugely expensive database license for every user on the system, while you really only need one. > 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. What you replicated is not what happens when your problem occurs. Processes don't do things like that with each others PID files. What's probably happening in your case is that there's a conflict with another copy of Postgres running; perhaps its running under the same user-id twice (or more) or on the same port? My suggestion would be to get rid of those extra copies of PG and just run one instance. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
