Re: Back-patch use of unnamed POSIX semaphores for Linux?

On Wed, Dec 7, 2016 at 7:18 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 7 December 2016 at 10:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Just saw another report of what's probably systemd killing off Postgres'
> > SysV semaphores, as we've discussed previously at, eg,
> > https://www.postgresql.org/message-id/flat/57828C31.5060409%40gmail.com
> > Since the systemd people are generally impervious to suggestions that
> > they might be mistaken, I do not expect this problem to go away.
> >
> > I think we should give serious consideration to back-patching commit
> > ecb0d20a9, which changed the default semaphore type to unnamed-POSIX
> > on Linux. We've seen no problems in the buildfarm in the two months
> > that that's been in HEAD. If we don't do this, we can expect to
> > continue seeing complaints of this sort until pre-v10 PG releases
> > fall out of use ... and I don't want to wait that long.
> >
> > Commit ecb0d20a9 also changed the default for FreeBSD. I'm not convinced
> > we should back-patch that part, because (a) unnamed-POSIX semas have
> > only been there since FreeBSD 9.0, which isn't that long ago, and (b)
> > the argument for switching is "it'll perform better" not "your server
> > will fail randomly without this change".
>
> That's a huge change to make for something that doesn't risk data
> corruption, and that won't happen when using postgres with distro
> packages.
>
> As I understand it, it's only a problem if you're running postgres as
> a normal user, not a "system user" which systemd defines at
> compile-time as a user < 500 or < 1000 depending on the distro's
> default login.conf . So it'll only affect people who're not using
> their distro's packages and service mechanism, and are instead running
> Pg under some other user, likely started manually with pg_ctl.
>
> I see quite a few people who compile their own Pg rather than using
> packages, and some who even fail to use the init system and instead
> use custom scripts to launch Pg. But pretty much everything I've seen
> uses a 'postgres' system-user. Clearly there are exceptions out there
> in the wild, but I don't think it makes sense to backpatch this to
> satisfy people who are, IMO, doing it wrong in the first place.
>
> Especially since those people can reconfigure systemd not to do this
> with the RemoveIPC and KillUserProcesses directives if they insist on
> using a non-system user.
>
> If they defined a systemd service to start postgres they'd be fine...
> and isn't it pretty much basic sysadmin 101 to use your init system to
> start services?
>
> Don't get me wrong, I think systemd's behaviour is pretty stupid.
> Mostly in terms of its magic definition of a "system user", which
> shouldn't be something determined by a uid threshold at compile time.
> But I don't think we should double down on it by backpatching a big
> change that hasn't even seen in-the-wild loads from real world use
> yet, just to make it easier on people who're doing things backwards in
> the first place.
>

+1 (or several).

I don't think we should backpatch something that carries risk for people
who do things "the right way" to help those that don't. Even if the
behavior is stupid.

>
> If it were possible to detect that systemd was about to clobber us and
> log something informative, _that_ would be very nice to backpatch. I
> don't see how that's possible though.

Surely there must be some way to ask systemd about it's configuration? And
if we have that, then we could possibly teach pg_ctl about that and have it
throw a big warning?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/