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
