Re: Compiling on Termux - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Compiling on Termux
Date
Msg-id 8911b02d-03cc-cb9b-3908-daa981e95ac8@2ndQuadrant.com
Whole thread Raw
In response to Re: Compiling on Termux  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Compiling on Termux
List pgsql-hackers
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.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Compiling on Termux
Next
From: David Rowley
Date:
Subject: Re: Performance issue in foreign-key-aware join estimation