Re: BUG #17949: Adding an index introduces serialisation anomalies. - Mailing list pgsql-bugs

From Thomas Munro
Subject Re: BUG #17949: Adding an index introduces serialisation anomalies.
Date
Msg-id CA+hUKGKuETgQ5a+uS2grX+muz5zEqCD36vM0xDt_C+Utx761nw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17949: Adding an index introduces serialisation anomalies.  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: BUG #17949: Adding an index introduces serialisation anomalies.  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-bugs
How is this schedule supposed to work?

S1:  _bt_search(&buf)
S1:  if (!BufferIsValid(buf)) // because index is empty
S1:  {
S1:    PredicateLockRelation(...);
S1:    ...
S1:    return false; // no tuples for you

S2:  _bt_search(&buf)

S1:  INSERT ...

S2:  if (!BufferIsValid(buf)) // because index *was* empty
S2:  {
S2:    PredicateLockRelation(...);
S2:    ...
S2:    return false; // no tuples for you

S2:  ...

My point is that S2 won't ever scan S1's tuples, so it won't pass S1's
xid to CheckForSerializableConflictOut().  Am I missing something?  I
can repro this with NR_THREADS set to only 2, after inserting
pg_usleep(1) after the _bt_search() in _bt_first() (sched_yield()
wasn't quite enough).



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17978: Unexpected error: "wrong varnullingrels (b) (expected (b 5)) for Var 6/2" triggered by JOIN
Next
From: Thomas Munro
Date:
Subject: Re: BUG #17949: Adding an index introduces serialisation anomalies.