Hitoshi Harada writes:
> OK. Looks better. But nentries should be bogus a little now?
No, I think it's fine as is. Essentially this logic says "attempt to
split when the new insertion would make us go over the target fill
factor", whereas the old logic split when the just-completed insertion
r
On Fri, Oct 19, 2012 at 11:40 AM, Tom Lane wrote:
> Hitoshi Harada writes:
>> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane 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 def
Hitoshi Harada writes:
> On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane 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
>> expa
On Thu, Oct 18, 2012 at 8:35 AM, Tom Lane wrote:
> I wrote:
>> Hitoshi Harada writes:
>>> If OOM happens during expand_table() in hash_search_with_hash_value()
>>> for RelationCacheInsert,
>
> the palloc-based allocator does throw
> errors. I think that when that was designed, we were thinking t
I wrote:
> Hitoshi Harada writes:
>> If OOM happens during expand_table() in hash_search_with_hash_value()
>> for RelationCacheInsert,
> What OOM? expand_table is supposed to return without doing anything
> if it can't expand the table. If that's not happening, that's a bug
> in the hash code.
Hitoshi Harada writes:
> If OOM happens during expand_table() in hash_search_with_hash_value()
> for RelationCacheInsert,
What OOM? expand_table is supposed to return without doing anything
if it can't expand the table. If that's not happening, that's a bug
in the hash code.
If OOM happens during expand_table() in hash_search_with_hash_value()
for RelationCacheInsert, the hash table entry is allocated and stored
in the hash table, but idhentry->reldesc remains NULL. Since OOM
causes AbortTransaction(), in AtEOXact_RelationCache() this NULL
pointer is referenced and we
