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

Thomas Munro <thomas.munro@enterprisedb.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