Re: [HACKERS] Predicate Locks for writes?

2017-10-13 Thread Alexander Korotkov
On Wed, Oct 11, 2017 at 7:27 PM, Robert Haas wrote: > On Wed, Oct 11, 2017 at 11:51 AM, Simon Riggs > wrote: > > I'm inclined to believe Robert's hypothesis that there is some race > > condition there. > > > > The question is whether that still

Re: [HACKERS] Predicate Locks for writes?

2017-10-11 Thread Robert Haas
On Wed, Oct 11, 2017 at 11:51 AM, Simon Riggs wrote: > 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

Re: [HACKERS] Predicate Locks for writes?

2017-10-11 Thread Simon Riggs
On 11 October 2017 at 15:33, Robert Haas wrote: > On Sat, Oct 7, 2017 at 7:26 AM, Simon Riggs wrote: >> PredicateLockTuple() specifically avoids adding an SIRead lock if the >> tuple already has a write lock on it, so surely it must also be >>

Re: [HACKERS] Predicate Locks for writes?

2017-10-11 Thread Robert Haas
On Sat, Oct 7, 2017 at 7:26 AM, Simon Riggs 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

Re: [HACKERS] Predicate Locks for writes?

2017-10-09 Thread Alexander Korotkov
On Sat, Oct 7, 2017 at 2:26 PM, Simon Riggs wrote: > SERIALIZABLE looks for chains of rw cases. > > When we perform UPDATEs and DELETEs we search for rows and then modify > them. The current implementation views that as a read followed by a > write because we issue

[HACKERS] Predicate Locks for writes?

2017-10-07 Thread Simon Riggs
SERIALIZABLE looks for chains of rw cases. When we perform UPDATEs and DELETEs we search for rows and then modify them. The current implementation views that as a read followed by a write because we issue PredicateLockTuple() during the index fetch. Is it correct that a statement that only