On Tue, Sep 26, 2017 at 7:56 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Hmm, so I tested this patch on my RHEL6 box (kernel 2.6.32) and it >> immediately fell over with >> 2017-09-25 14:23:48.410 EDT [325] FATAL: could not resize shared memory >> segment "/PostgreSQL.1682054886" to 6928 bytes: Operation not supported >> during startup. I wonder whether we need to round off the request. > > Nope, rounding off doesn't help. What does help is using posix_fallocate > instead. I surmise that glibc knows something we don't about how to call > fallocate(2) successfully on this kernel version. > > Rather than dig into the guts of glibc to find that out, though, I think > we should just s/fallocate/posix_fallocate/g on this patch. The argument > for using the former seemed pretty thin to begin with.
I didn't dig into the glibc source but my first guess is that posix_fallocate() sees ENOTSUPP (from tmpfs on that vintage kernel) and falls back to a write loop. I thought I was doing enough by testing for ENOSYS (based on the man page for fallocate which said that should be expected on kernels < 2.6.23), but I see now that ENOTSUPP is possible per-filesystem implementation and tmpfs support was added some time after the 2.6.32 era: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2d12e22c59ce714008aa5266d769f8568d74eac I'm not sure why glibc would provide a fallback for posix_fallocate() but let ENOTSUPP escape from fallocate(). -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers