Craig Ringer <craig@2ndquadrant.com> writes: > As I understand it, because we allow multiple Pg instances on a system, we > identify the small sysv shmem segment we use by the postmaster's pid. If > you remove the DirLockFile (postmaster.pid) you remove the interlock > against starting a new postmaster. It'll think it's a new independent > instance on the same host, make a new shmem segment and go merrily on its > way mangling data horribly.
Yeah. If we realized that the old shmem segment was associated with this data directory, we could check for processes still attached to it ... but the lock file is exactly where that association is kept. > It'd be nice if the OS offered us some support here. Something like opening > a lockfile in exclusive lock mode, then inheriting the FD and lock on all > children, with each child inheriting the lock. So the exclusive lock > wouldn't get released until all FDs associated with it are released. But > AFAIK nothing like that is present, let alone portable.
I've wondered about that too. An inheritable lock on the data directory itself would be ideal, but that doesn't exist anywhere AFAIK. We could imagine taking a BSD-style-flock(2) lock on some lock file, on systems that have that; but not all do, so it couldn't be our only protection. Another problem is that since it'd have to be an ordinary file, there'd still be a risk of cowboy DBAs removing the lock file. Maybe we could use pg_control as the lock file?
"The error mentioned that there was another active database using this pg_control file, so I deleted it, and now my database won't start."
Like our discussion about pg_resetxlog, there's a limit to how much operator error we can guard against. More importantly we'd have to be _very_ sure it was correct or our attempts to protect the user would risk creating a major outage.
That said, flock(2) with LOCK_NB seems to have just the semantics we want:
"
A single file may not simultaneously have both shared and exclusive locks.
Locks created by flock() are associated with an open file description (see open(2)). This means that duplicate file descriptors (created by, for example, fork(2) or dup(2)) refer to the same lock,
and this lock may be modified or released using any of these file descriptors. Furthermore, the lock is released either by an explicit LOCK_UN operation on any of these duplicate file descriptors,
or when all such file descriptors have been closed.
"
Worth looking into, but really important not to make a mistake and make things worse.
