Re: Contention preventing locking

On Tue, Feb 20, 2018 at 10:34 PM, Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>
>
> On 20.02.2018 19:39, Simon Riggs wrote:
>>
>> On 20 February 2018 at 16:07, Konstantin Knizhnik
>> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>>>
>>>
>>> On 20.02.2018 14:26, Simon Riggs wrote:
>>>>
>>>> Try locking the root tid rather than the TID, that is at least unique
>>>> per page for a chain of tuples, just harder to locate.
>>>>
>>> As far as I understand, it is necessary to traverse the whole page to
>>> locate
>>> root tuple, isn't it?
>>> If so, then I expect it to be too expensive operation. Scanning the whole
>>> page on tuple update seems to be not an acceptable solution.
>>
>> Probably.
>>
>> It occurs to me that you can lock the root tid in index_fetch_heap().
>> I hear other DBMS lock via the index.
>>
>> However, anything you do with tuple locking could interact badly with
>> heap_update and the various lock modes, so be careful.
>>
>> You also have contention for heap_page_prune_opt() and with SELECTs to
>> consider, so I think you need to look at both page and tuple locking.
>>
>
> So, if I correctly understand the primary goal of setting tuple lock in
> heapam.c is to avoid contention caused
> by concurrent release of all waiters.
> But my transaction lock chaining patch eliminates this problem in other way.
> So what about combining your patch (do not lock Snapshot.xmax) + with my
> xlock patch and ... completely eliminate tuple lock in heapam?
> In this case update of tuple will require obtaining just one heavy weight
> lock.
>
> I made such experiment and didn't find any synchronization problems with my
> pgrw test.
> Performance is almost the same as with vanilla+xlock patch:
>
> https://docs.google.com/spreadsheets/d/1QOYfUehy8U3sdasMjGnPGQJY8JiRfZmlS64YRBM0YTo/edit?usp=sharing
>
> I wonder why instead of chaining transaction locks (which can be done quite
> easily) approach with extra tuple lock was chosen?

Can you please explain, how it can be done easily without extra tuple
locks? I have tried to read your patch but due to lack of comments,
it is not clear what you are trying to achieve. As far as I can see
you are changing the locktag passed to LockAcquireExtended by the
first waiter for the transaction. How will it achieve the serial
waiting protocol (queue the waiters for tuple) for a particular tuple
being updated?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com