From: Amit Kapila [mailto:amit.kapila16@gmail.com]
> > Hmm, the large-page requires contiguous memory for each page, so this
> error could occur on a long-running system where the memory is heavily
> fragmented. For example, please see the following page and check the memory
> with RAMMap program referred there.
> >
>
> I don't have RAMMap and it might take some time to investigate what is going
> on, but I think in such a case even if it works we should keep the default
> value of huge_pages as off on Windows. I request somebody else having
> access to Windows m/c to test this patch and if it works then we can move
> forward.
You are right. I modified the patch so that the code falls back to the non-huge page when CreateFileMapping() fails
dueto the shortage of large pages. That's what the Linux version does.
The other change is to parameterize the Win32 function names in the messages in EnableLockPagePrivileges(). This is to
avoidadding almost identical messages unnecessarily. I followed Alvaro's comment. I didn't touch the two existing
sitesthat embed Win32 function names. I'd like to leave it up to the committer to decide whether to change as well,
becausechanging them might make it a bit harder to apply some bug fixes to earlier releases.
FYI, I could reproduce the same error as Amit on 32-bit Win7, where the total RAM is 3.5 GB and available RAM is 2 GB.
Iused the attached largepage.c. Immediately after the system boot, I could only allocate 8 large pages. When I first
triedto allocate 32 large pages, the test program produced:
large page size = 2097152
allocating 32 large pages...
CreateFileMapping failed: error code = 1450
You can build the test program as follows:
cl largepage.c advapi32.lib
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
