aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeSetOp.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-10-13 15:06:46 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-10-13 15:06:46 -0400
commitcb775768e3e37d466d69b7177a92508b81c1c204 (patch)
tree6e28041cff53fafb4c0385402ba056af49e52631 /src/backend/executor/nodeSetOp.c
parent15fc5e15811337f5a81d4ae44c6149256f6dd15f (diff)
downloadpostgresql-cb775768e3e37d466d69b7177a92508b81c1c204.tar.gz
postgresql-cb775768e3e37d466d69b7177a92508b81c1c204.zip
Try to find out the actual hugepage size when making a MAP_HUGETLB request.
Even if Linux's mmap() is okay with a partial-hugepage request, munmap() is not, as reported by Chris Richards. Therefore it behooves us to try a bit harder to find out the actual hugepage size, instead of assuming that we can skate by with a guess. For the moment, just look into /proc/meminfo to find out the default hugepage size, and use that. Later, on kernels that support requests for nondefault sizes, we might try to consider other alternatives. But that smells more like a new feature than a bug fix, especially if we want to provide any way for the DBA to control it, so leave it for another day. I set this up to allow easy addition of platform-specific code for non-Linux platforms, if needed; but right now there are no reports suggesting that we need to work harder on other platforms. Back-patch to 9.4 where hugepage support was introduced. Discussion: <31056.1476303954@sss.pgh.pa.us>
Diffstat (limited to 'src/backend/executor/nodeSetOp.c')
0 files changed, 0 insertions, 0 deletions