Re: RFC: Add 'taint' field to pg_control.

On 8 March 2018 at 12:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Craig Ringer <craig(at)2ndquadrant(dot)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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services