On Wed, Dec 7, 2016 at 7:18 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:
> On 7 December 2016 at 10:53, Tom Lane <t...@sss.pgh.pa.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/
