On 26.02.2018 17:20, Amit Kapila wrote:
On Tue, Feb 20, 2018 at 10:34 PM, Konstantin Knizhnik
<k.knizh...@postgrespro.ru> wrote:
On 20.02.2018 19:39, Simon Riggs wrote:
On 20 February 2018 at 16:07, Konstantin Knizhnik
<k.knizh...@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
