On Mon, Feb 18, 2019 at 10:26 AM Thomas Munro <thomas.mu...@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
0001-Fix-inconsistent-out-of-memory-error-reporting-in-ds.patch
Description: Binary data
