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
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
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
>>
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
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
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