On 11 October 2017 at 15:33, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Oct 7, 2017 at 7:26 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> PredicateLockTuple() specifically avoids adding an SIRead lock if the
>> tuple already has a write lock on it, so surely it must also be
>> correct to skip the SIRead lock if we are just about to update the
>> row?
>
> I wonder if there's a race condition. Can someone else read/update
> the tuple between the time when we would've taken the SIRead lock and
> the time when we would have gotten the actual tuple lock?
On 9 October 2017 at 13:23, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
>> PredicateLockTuple() specifically avoids adding an SIRead lock if the
>> tuple already has a write lock on it, so surely it must also be
>> correct to skip the SIRead lock if we are just about to update the
>> row?
>>
>> I am suggesting that we ignore PredicateLockTuple() for cases where we
>> are about to update or delete the found tuple.
>
>
> If my thoughts above are correct, than it would be a reasonable
> optimization. We would skip cycle of getting SIReadLock on tuple and then
> releasing it, without any change of behavior.
I'm inclined to believe Robert's hypothesis that there is some race
condition there.
The question is whether that still constitutes a serializability
problem since we haven't done anything with the data, just passed it
upwards to be modified.
If not we can just skip the SIread lock.
If it is an issue that still leaves the optimization in the case where
we choose to locate the row using an exclusive lock and just skip the
SIread lock altogether.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
