I wrote:
>>> I suspect that huge INIT_TABLE_SIZE prevented dynamic expanding the
>>> hash tables and seems there's something wrong in the routines
>>> responsible for that.
> OK, as the last guy to touch dynahash.c I suppose this is my
> bailiwick... I will look into it today.
It's amazing how much easier it is to see a bug when you know it must be
there ;-).
I discovered that the hashtable expansion routine would mess up in the
case that all the records in the bucket being split ended up in the new
bucket rather than the old. In that case it forgot to clear the old
bucket's chain header, with the result that all the records appeared to
be in both buckets at once. This would not be a big problem until and
unless the first record in the chain got deleted --- it would only be
correctly removed from the new bucket, leaving the old bucket's chain
header pointing at a now-free record (and failing to link to any records
that had been added to the shared chain on its behalf in the meanwhile).
Disaster ensues.
An actual failure via this path seems somewhat improbable, but that
may just explain why we hadn't seen it happen very much before...
I have committed a fix in dynahash.c. Hiroshi and Tatsuo, would you
please grab latest sources and see whether the problems you are
observing are fixed?
regards, tom lane
