On Mon, Feb 18, 2019 at 10:26 AM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> 1. "dsa_allocate could not find %zu free pages": freepage.c, fixed in 7215efdc.
> 2. "dsa_area could not attach to segment": dsm.c, fixed in 6c0fb941.
> 3. "cannot unpin a segment that is not pinned": dsm.c, fixed in 0b55aaac.
>
> That resolves all the bugs I'm currently aware of in this area.
Bleugh. After that optimistic statement, Justin reminded me of a
one-off segfault report hiding over on the pgsql-performance list[1].
That was buried in a bunch of discussion of bug #1 in the above list,
which is now fixed. However, the segfault report was never directly
addressed.
After thinking really hard and doubling down on coffee, I think I know
how it happened -- actually it's something I have mentioned once
before as a minor defect, but I hadn't connected all the dots. Bug #1
above was occurring occasionally in Jakub's workload, and there is a
path through the code that would result in plain old allocation
failure instead of raising FATAL error #1, and a place where failure
to allocate can return InvalidDsaPointer instead of raising an "out of
memory" error so that calling code could finish up eating a null
pointer that it wasn't expecting (that's user controllable, using the
DSA_ALLOC_NO_OOM flag, but that one place didn't respect it). Here is
a patch that fixes those problems.
[1] https://postgr.es/m/CAJk1zg3ZXhDsFg7tQGJ3ZD6N9dp%2BQ1_DU2N3%3Ds3Ywb-u6Lhc5A%40mail.gmail.com
--
Thomas Munro
http://www.enterprisedb.com
