On Sun, Aug 26, 2012 at 1:25 PM, Alban Hertroys wrote:
> > We back our client application with PG,
>
> > each OSX user gets their own instance of PG.
>
> Are you certain that's necessary?
>
>
It was a decision made, weighing various trade-offs, 4 years ago now.
> > In the wild this scenario has
On 26 Aug 2012, at 17:21, Michael Clark wrote:
> On Sun, Aug 26, 2012 at 10:25 AM, Tom Lane wrote:
>> Michael Clark 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
On Sun, Aug 26, 2012 at 10:25 AM, Tom Lane wrote:
> Michael Clark 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.
It runs as that OSX user.
>
Michael Clark writes:
> It does in fact appear that we are getting false-positives.
> When trying to start PG using pg_ctl, I am getting this response:
> pg_ctl: another server might be running; trying to start server anyway
> 2012-08-26 04:46:02.211 GMT [] - FATAL: lock file "postmaster.pid" alr
On 08/25/12 9:56 PM, Michael Clark wrote:
PID 8574 is actually iTunes, not PG, and PG was cleanly brought down
on it's last run, there are no children processes running.
when postgres is cleanly brought down, the postgresql.pid file is
supposed to be removed. that file contains the PID that
On Mon, Aug 20, 2012 at 11:30 PM, Tom Lane wrote:
> Sebastien Boisvert writes:
> > Is this mechanism documented anywhere (besides source code)?
>
> No, not really.
>
> > It looks like PG will only clean it up if there's no other process
> running at all on the pid listed in the postmaster.pid fi
Sebastien Boisvert writes:
> Is this mechanism documented anywhere (besides source code)?
No, not really.
> It looks like PG will only clean it up if there's no other process running at
> all on the pid listed in the postmaster.pid file, even if any process running
> on that pid isn't a PG pro
Is this mechanism documented anywhere (besides source code)?
It looks like PG will only clean it up if there's no other process running at
all on the pid listed in the postmaster.pid file, even if any process running
on that pid isn't a PG process or there's no server running on the data
direct
Sebastien Boisvert writes:
> I vaguely remember reading in the release notes (around the time 9.x was
> released) something about it automatically clearing out the postmaster.pid
> file if it was found to be stale/invalid when starting the the database
> server, however I cannot find any refere
Jen,
Regarding the first point, is postgres actually running? You can check this
by typing the following at a terminal -
ps -ef|grep postgres
Reload configuration is used to tell PostgreSQL to read in the configuration
file for any chances since the database started. If you want to start the
d
"Ian Harding" <[EMAIL PROTECTED]> writes:
> The docs state that postmaster.pid is "A lock file recording the
> current postmaster PID and shared memory segment ID (not present after
> postmaster shutdown"
> I never looked until now, but I see the number 5432001 where the pid
> should be, and the re
11 matches
Mail list logo
