Re: New feature proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New feature proposal
Date
Msg-id 3030.1148064272@sss.pgh.pa.us
Whole thread Raw
In response to Re: New feature proposal  (Marc Munro <marc@bloodnok.com>)
Responses Re: New feature proposal  (Marc Munro <marc@bloodnok.com>)
List pgsql-hackers
Marc Munro <marc@bloodnok.com> writes:
> My proposal makes it possible for properly configured add-ins to have a
> guaranteed amount of shared memory available.

This could all be solved in a cleaner, more bulletproof way if you
simply require such add-ins to be preloaded into the postmaster process
using the existing preload_libraries hook.  Then, such an add-in would
allocate its own shmem segment independent of the main Postgres one.
This totally eliminates worries about one chunk of code eating the other
one's memory, which otherwise we'd have to have additional mechanism to
deal with.

In a Unix environment, such a thing would Just Work because pointers to
the new segment would be inherited through fork().  In the Windows port
you'd need to do more pushups --- perhaps allocate a small amount of
memory in the main Postgres shmem segment containing the ID of the other
shmem segment, which a backend would use to reattach.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [OT] MySQL is bad, but THIS bad?
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [OT] MySQL is bad, but THIS bad?