Re: dsa_allocate could not find 4 free pages

On Wed, Dec 6, 2017 at 9:35 AM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
>> On Dec 5, 2017, at 11:25 AM, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> Does the plan have multiple Gather nodes with Parallel Bitmap Heap Scan?
>
> This was encountered and logged by a java client. The only data I got was:
>
> org.postgresql.util.PSQLException: ERROR: dsa_allocate could not find 4 free pages
> Where: parallel worker

This means that the DSA area is corrupted. Presumably
get_best_segment(area, 4) returned a segment that wasn't actually good
for 4 pages, either because it was incorrectly binned or because its
free space btree was corrupted. Another path would be that
make_new_segment(area, 4) returned a segment that couldn't find 4
pages, but that seems unlikely.

> [query plan with one Gather and no Parallel Bitmap Heap Scan]

I'm not sure why this plan would ever call dsa_allocate().

> [query plan with no Gather but plenty of Btimap Heap Scans]

And this one certainly can't. I guess you must sometimes get a
different variation that has Gather nodes and uses Parallel Bitmap
Heap Scan. Then the question is whether the es_query_dsa multiple
Gather bug can explain this: for example, if dsa_free(wrong_dsa_area,
p) was called, perhaps it could produce this type of corruption.
Otherwise we have a different bug. Any clues on how to reproduce the
problem would be very welcome.

--
Thomas Munro
http://www.enterprisedb.com