3 ms·
Like other comments here state, in general, use what you know. That said, postgresql has ~always been the better rdbms. Some would argue mysql at times have bee
by e12e 9y ago
Like other comments here state, in general, use what you know. That said, postgresql has ~always been the better rdbms. Some would argue mysql at times have been a better ~key-value store with ~sql interface.
Apparently postgresql is difficult to run in a properly restricted bsd jail. Other than that, I'd be hard pressed to come up with reasons to prefer mysql on technical merit over either postgresql, or, say redis or something.
- Avernar 9y agoI'm running postgresql in a FreeBSD vnet jail without issue. The network stack is not shared as it's a vnet jail. I have it set for per jail sysvipc, new in FreeBSD 11, which was the last thing I needed to fully isolate it from other jails. Is there anything else that's needed to properly restrict the jail?
- e12e 9y agoMostly that afaik a jail with sysvipc set isn't really isolated any more - it works, but defeats some of the purpose of using a jail in the first place? https://forums.freebsd.org/threads/59371/ https://forums.freebsd.org/threads/59371/ Apparently this can(should?) be tweaked a bit since 11-release: https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=&n=1 https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=&n=1 > allow.sysvipc A process within the jail has access to System V IPC primitives. This is deprecated in favor of the per-mod- ule parameters (see below). When this parameter is set, it is equivalent to setting sysvmsg, sysvsem, and sysvshm all to ``inherit''. I interpret that as it still being the case that setting this to the (equivalent of) the deprecated setting, one looses much of the protection a jail normally gives.