Re: Postgres, fsync, and OSs (specifically linux)
От | Andres Freund |
---|---|
Тема | Re: Postgres, fsync, and OSs (specifically linux) |
Дата | |
Msg-id | 20180428161105.l46ipcjyce4t56ey@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Postgres, fsync, and OSs (specifically linux) (Michael Banck <michael.banck@credativ.de>) |
Список | 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
В списке pgsql-hackers по дате отправления: