Magnus Hagander <mag...@hagander.net> writes:
> One proposed fix is to allocate a fairly large block of memory in the
> postmaster just before we get the shared memory, and then free it right
> away. The effect should be to push down the shared memory segment
> further in the address space.
I have no enthusiasm for doing something like this when we have so
little knowledge of what's actually happening. We have *no* idea
whether the above could help, or what size of allocation to request.
It's not very hard to imagine that the wrong size choice could make
things worse rather than better.
It seems to me that what we ought to do now is make a serious effort
to gather more data. I came across a suggestion that one could use
VirtualQuery() to generate a map of the process address space
under Windows. I suggest that we add some code that is executed
if the reattach attempt fails and dumps the process address space
details to the postmaster log. Dumping the postmaster's address
space at the time it successfully creates the shmem segment might
be useful for comparison, too.
(A quick look at the VirtualQuery spec indicates that you can't tell
very much beyond free/allocated status, though. Maybe there's some
other call that would tell more? It'd be really good if we could get
the names of DLLs occupying memory ranges, for example.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
