Re: Contention preventing locking

On 26.02.2018 17:20, Amit Kapila wrote:
> On Tue, Feb 20, 2018 at 10:34 PM, Konstantin Knizhnik
> <k.knizhnik@postgrespro.ru> wrote:
>>
>> On 20.02.2018 19:39, Simon Riggs wrote:
>>> On 20 February 2018 at 16:07, Konstantin Knizhnik
>>> <k.knizhnik@postgrespro.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?
>
The idea of transaction lock chaining was very simple. I have explained 
it in the first main in this thread.
Assumed that transaction T1 has updated tuple R1.
Transaction T2 also tries to update this tuple and so waits for T1 XID.
If then yet another transaction T3 also tries to update R1, then it 
should wait for T2, not for T1.
In this case commit of transaction T1 will awake just one transaction 
and not all other transaction pretending to update this tuple.
So there will be no races between multiple transactions which consume a 
lot of system resources.

Unfortunately the way i have implemented this idea: release lock of the 
original XID and tries to obtain lock of the XID of last waiting 
transaction can lead to deadlock.

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company