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 constitutes a serializability
> > problem since we
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 passed it
> upwards to be
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
>> correct to skip the SIRead lock if we are just about
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 if there's a race condi
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 PredicateLockTuple() during the
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 change