Re: hash_search and out of memory

On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
>> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm not terribly comfortable with trying to use a PG_TRY block to catch
>>> an OOM error - there are too many ways that could break, and this code
>>> path is by definition not very testable. I think moving up the
>>> expand_table action is probably the best bet. Will you submit a patch?
>
>> Here it is. I factored out the bucket finding code to re-calculate it
>> after expansion.
>
> I didn't like that too much. I think a better solution is just to do
> the table expansion at the very start of the function, along the lines
> of the attached patch. This requires an extra test of the "action"
> parameter, but I think that's probably cheaper than an extra function
> call. It's definitely cheaper than recalculating the hash etc when
> a split does occur.
>

OK. Looks better. But nentries should be bogus a little now?

+ /*
+ * Can't split if running in partitioned mode, nor if frozen, nor if
+ * table is the subject of any active hash_seq_search scans. Strange
+ * order of these tests is to try to check cheaper conditions first.
+ */
+ if (!IS_PARTITIONED(hctl) && !hashp->frozen &&
+ hctl->nentries / (long) (hctl->max_bucket + 1) >= hctl->ffactor &&
+ !has_seq_scans(hashp))
+ (void) expand_table(hashp);

hctl->nentries + 1 sounds appropriate?

Thanks,
--
Hitoshi Harada