Tom,
>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?
Bingo! Your fix seems to solve the problem! Now 64 concurrent
transactions ran 100 transactions each without any problem. Thanks.
BTW, the script I'm using for the heavy load testing is written in
Java(not written by me). Do you want to try it?
>> (1) without -B 1024, it failed: out of free buffers: time to abort!
>
>Right now, the postmaster will let you set any combination of -B and -N
>you please. But it seems obvious that there is some minimum number of
>buffers per backend below which things aren't going to work very well.
>I wonder whether the postmaster startup code ought to enforce a minimum
>ratio, say -B at least twice -N ? I have no idea what an appropriate
>limit would be, however. Vadim, do you have any thoughts?
Just a few questions.
o I observed the backend processes grew ~10MB with -B 1024. Is this
normal?
o Is it possible to let the backend wait for free buffers in case of
insufficient shared buffers? (with reasonable retries, of course)
--
Tatsuo Ishii
