Exactly so :-) (Seems simpler and I wouldn't have thought it would be a
problem to just remove the one, very small, file after the copy)
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Postgres-running-but-no-postmaster-pid-tp4662510p4662780.html
Sent from the PostgreSQL
Excerpts from simon.marshall's message of mié ago 03 11:56:55 -0400 2011:
> In fact, looking at it further, we stop the database (only continuing if this
> succeeds), copy our backup data over, remove the copied over postmaster.pid,
> make some config. changes and then (again, only if all this succ
In fact, looking at it further, we stop the database (only continuing if this
succeeds), copy our backup data over, remove the copied over postmaster.pid,
make some config. changes and then (again, only if all this succeeds), start
the database again, which should surely recreate postmaster.pid?
-
Thanks for your speedy response Tom. Seems like that is indeed what happens
elsewhere in the convoluted mess that are our backup scripts. Am
disappointed I didn't think of grepping for that myself! Too high a view of
my colleagues, now going downhill ;-)
Thanks,
Simon
--
View this message in cont
"simon.marshall" writes:
> When I came to stop my postgres instance (in particular, a replication
> database using postgres version 9.0.3 running on port 5442) today it failed
> to stop because the postmaster.pid instance wasn't present, despite the
> process still running (seen by running ps -eaf
Hi guys,
When I came to stop my postgres instance (in particular, a replication
database using postgres version 9.0.3 running on port 5442) today it failed
to stop because the postmaster.pid instance wasn't present, despite the
process still running (seen by running ps -eaf | grep post and noting
