On Wed, Oct 5, 2016 at 10:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 12:36 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> I think one way to avoid the risk of deadlock in above scenario is to
>> take the cleanup lock conditionally, if we get the cleanup lock then
>> we will delete the items as we are doing in patch now, else it will
>> just mark the tuples as dead and ensure that it won't try to remove
>> tuples that are moved-by-split. Now, I think the question is how will
>> these dead tuples be removed. We anyway need a separate mechanism to
>> clear dead tuples for hash indexes as during scans we are marking the
>> tuples as dead if corresponding tuple in heap is dead which are not
>> removed later. This is already taken care in btree code via
>> kill_prior_tuple optimization. So I think clearing of dead tuples can
>> be handled by a separate patch.
>
> That seems like it could work. The hash scan code will need to be
> made smart enough to ignore any tuples marked dead, if it isn't
> already.
>
It already takes care of ignoring killed tuples in below code, though
the way is much less efficient as compare to btree. Basically, it
fetches the matched tuple and then check if it is dead where as in
btree while matching the key, it does the same check. It might be
efficient to do it before matching the hashkey, but I think it is a
matter of separate patch.
hashgettuple()
{
..
/*
* Skip killed tuples if asked to.
*/
if (scan->ignore_killed_tuples)
}
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
