On Sat, Dec 22, 2018 at 9:19 AM David Fetter <david@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 <david@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