Re: Postgres, fsync, and OSs (specifically linux)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Banck <michael.banck@credativ.de>
Cc: Stephen Frost <sfrost@snowman.net>, Craig Ringer <craig@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-28T16:11:05Z
Lists: pgsql-hackers
Hi, On 2018-04-28 17:35:48 +0200, Michael Banck wrote: > This dmesg-checking has been mentioned several times now, but IME > enterprise distributions (or server ops teams?) seem to tighten access > to dmesg and /var/log to non-root users, including postgres. > > Well, or just vanilla Debian stable apparently: > > postgres@fock:~$ dmesg > dmesg: read kernel buffer failed: Operation not permitted > > Is it really a useful expectation that the postgres user will be able to > trawl system logs for I/O errors? Or are we expecting the sysadmins (in > case they are distinct from the DBAs) to setup sudo and/or relax > permissions for this everywhere? We should document this requirement > properly at least then. I'm not a huge fan of this approach, but yes, that'd be necessary. It's not that problematic to have to change /dev/kmsg permissions imo. Adding a read group / acl seems quite doable. > The netlink thing from Google that Tet Ts'O mentioned would probably > work around that, but if that is opened up it would not be deployed > anytime soon either. Yea, that seems irrelevant for now. Greetings, Andres Freund
Commits
-
PANIC on fsync() failure.
- 9ccdd7f66e33 12.0 landed
- f1ff5f51d249 9.4.21 landed
- 312435232217 9.5.16 landed
- b9cce9ddfa17 9.6.12 landed
- afbe03f65470 10.7 landed
- 6534d544cd77 11.2 landed
-
Fix and improve pg_atomic_flag fallback implementation.
- 8c3debbbf618 11.0 cited