"Peter Kovacs" <maxottovonstirlitz@gmail.com> writes:
> Please, could you tell me why the pid file is not deleted on shutdown?
It looks to me like the postmaster isn't being given enough time to
finish shutdown before being forcibly killed. This is not great,
but in theory we should always be able to recover from that. You might
want to look to see if you can't extend the SIGTERM-to-SIGKILL delay
though.
> On system startup PostgreSQL 8.1.4 refuses to start due to the pid
> file is left over from previous "session" on Solaris 10 x86.
That should not happen; it should always be possible to detect whether
the file is stale, *if* your start script is written correctly. Per
the comment in miscinit.c:
* If the PID in the lockfile is our own PID or our parent's PID, then
* the file must be stale (probably left over from a previous system
* boot cycle). We need this test because of the likelihood that a
* reboot will assign exactly the same PID as we had in the previous
* reboot. Also, if there is just one more process launch in this
* reboot than in the previous one, the lockfile might mention our
* parent's PID. We can reject that since we'd never be launched
* directly by a competing postmaster. We can't detect grandparent
* processes unfortunately, but if the init script is written
* carefully then all but the immediate parent shell will be
* root-owned processes and so the kill test will fail with EPERM.
*
* We can treat the EPERM-error case as okay because that error
* implies that the existing process has a different userid than we
* do, which means it cannot be a competing postmaster.
If the start script is written in a way that creates multiple levels of
postgres-owned processes, you should fix it. On Linux something
like this works:
su -l postgres -c "/usr/bin/postmaster ... &" >> "$PGLOG" 2>&1 < /dev/null
Don't use "su 'pg_ctl ...'" to start the postmaster, because it creates
exactly the hazard situation of an extra postgres-owned process.
Also, if you are trying to start multiple postmasters at boot, this
technique is insufficient unless you run each one under a distinct userid
(which is probably a good idea anyway on security grounds).
regards, tom lane