On Wed, Jun 27, 2012 at 9:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Would Posix shmem help with that at all? Why did you choose not to >>> use the Posix API, anyway? > >> It seemed more complicated. If we use the POSIX API, we've got to >> have code to find a non-colliding name for the shm, and we've got to >> arrange to clean it up at process exit. Anonymous shm doesn't require >> a name and goes away automatically when it's no longer in use. > > I see. Those are pretty good reasons ...
So, should we do it this way? I did a little research and discovered that Linux 2.3.51 (released 3/11/2000) apparently returns EINVAL for MAP_SHARED|MAP_ANONYMOUS. That combination is documented to work beginning in Linux 2.4.0. How worried should we be about people trying to run PostgreSQL 9.3 on pre-2.4 kernels? If we want to worry about it, we could try mapping a one-page shared MAP_SHARED|MAP_ANONYMOUS segment first. If that works, we could assume that we have a working MAP_SHARED|MAP_ANONYMOUS facility and try to allocate the whole segment plus a minimal sysv shm. If the single page allocation fails with EINVAL, we could fall back to allocating the entire segment as sysv shm. A related question is - if we do this - should we enable it only on ports where we've verified that it works, or should we just turn it on everywhere and fix breakage if/when it's reported? I lean toward the latter. If we find that there are platforms where (a) mmap is not supported or (b) MAP_SHARED|MAP_ANON works but has the wrong semantics, we could either shut off this optimization on those platforms by fiat, or we could test not only that the call succeeds, but that it works properly: create a one-page mapping and fork a child process; in the child, write to the mapping and exit; in the parent, wait for the child to exit and then test that we can read back the correct contents. This would protect against a hypothetical system where the flags are accepted but fail to produce the correct behavior. I'm inclined to think this is over-engineering in the absence of evidence that there are platforms that work this way. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
