From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Chris Richards <chris(at)infinite(dot)io>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: LOG: munmap(0x7fff80000000) failed: Invalid argument |
Date: | 2016-10-11 00:45:40 |
Message-ID: | 23429.1476146740@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-10-10 18:21:48 -0400, Tom Lane wrote:
>> Chris Richards <chris(at)infinite(dot)io> writes:
>>> LOG: munmap(0x7fff80000000) failed: Invalid argument
>> [ digs in code... ] One theory is that PGSharedMemoryDetach is getting
>> called more than once, but I'm not sure how that would happen. Can you
>> characterize where this happens more precisely? What nondefault settings
>> have you got in postgresql.conf?
> Hm. Could that be from the DSM code?
That particular error message spelling only appears in sysv_shmem.c,
so it's not directly DSM's fault.
The comments around PGSharedMemoryDetach strongly suggest that it ought
to be a no-op if called twice, which it originally was but fails to be
since the addition of the munmap call. So I'm *very* strongly tempted
to add "AnonymousShmem = NULL;" there and in IpcMemoryDetach. But
it's not evident why we've not seen this behavior many times already,
so I'd kind of like to find out what's different about Chris's use-case
before assuming that that will fix it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Periko Support | 2016-10-11 00:45:55 | Re: [SPAM] psql 9.3 automatic recovery in progress |
Previous Message | Andres Freund | 2016-10-11 00:32:09 | Re: LOG: munmap(0x7fff80000000) failed: Invalid argument |