Re: BUG #15225: [XX000] ERROR: invalid DSA memory alloc request size 1073741824 / Where: parallel worker

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> Here is a tidier version that I'd like to commit before beta2, if
> there are no objections. I've added this to the PostgreSQL 11 open
> items page.

That looks fine as far as it goes. But I noticed that the code that
actually resizes the hashtable looks like

/* Double the size of the bucket array. */
pstate->nbuckets *= 2;
size = pstate->nbuckets * sizeof(dsa_pointer_atomic);
hashtable->batches[0].shared->size += size / 2;
dsa_free(hashtable->area, hashtable->batches[0].shared->buckets);
hashtable->batches[0].shared->buckets =
dsa_allocate(hashtable->area, size);
buckets = (dsa_pointer_atomic *)
dsa_get_address(hashtable->area,
hashtable->batches[0].shared->buckets);
for (i = 0; i < pstate->nbuckets; ++i)
dsa_pointer_atomic_init(&buckets[i], InvalidDsaPointer);

with no apparent provision for failure of the realloc. So the first
question is does the query actually fail cleanly if dsa_allocate gets
an OOM, and the second is whether we really want to fail the query in
such a case, rather than plow ahead with the existing bucket array.

BTW, that method of updating shared->size would do credit to
Rube Goldberg. Wouldn't this:

hashtable->batches[0].shared->size = size;

be both faster and less confusing?

regards, tom lane