On Sat, Dec 22, 2018 at 9:19 AM David Fetter <da...@fetter.org> wrote: > On Fri, Dec 21, 2018 at 04:24:20PM -0500, Andrew Dunstan wrote: > > On 12/21/18 4:04 PM, Thomas Munro wrote: > > > On Sat, Dec 22, 2018 at 7:32 AM David Fetter <da...@fetter.org> wrote: > > >> On Sat, Dec 22, 2018 at 07:03:32AM +1100, Thomas Munro wrote: > > >>> That talks about using -D__ANDROID_API__=23 (or presumably higher) to > > >>> make sure that sigtimedwait is exposed by signal.h. Something similar > > >>> may be afoot here. > > >> That worked perfectly...to expose the next issue, namely that at least > > >> part of the System-V IPC mechanisms have been left out. Do we support > > >> other systems where this is true? > > > Interesting, they left that stuff out deliberately out basically > > > because it all sucks: > > > > > > https://android.googlesource.com/platform/ndk/+/4e159d95ebf23b5f72bb707b0cb1518ef96b3d03/docs/system/libc/SYSV-IPC.TXT > > > > > > PostgreSQL currently needs SysV shm just for the small segment that's > > > used for preventing multiple copies running in the same pgdata. You'd > > > need to find a new way to do that. We don't use SysV semaphores > > > (though we can) or message queues. > > > > That doc says: > > > > Killing processes automatically to make room for new ones is an > > important part of Android's application lifecycle implementation. > > > > How's that going to play with Postgres? Sounds like the OOM killer on > > steroids. > > I don't know precisely how it's going to play with Postgres, but > Termux does supply a Postgres in its native packages. That package > appears to work, at least in the single-connection case, so they're > doing something somehow to get it up and running. > > It could be that Android won't be a platform we recommend for high > workloads, at least as long as these things remain true.
They use libandroid-shmem which emulates SysV shmem. https://github.com/termux/termux-packages/blob/master/packages/postgresql/src-backend-Makefile.patch https://github.com/termux/libandroid-shmem -- Thomas Munro http://www.enterprisedb.com
