On Wed, May 15, 2019 at 6:50 PM Andres Freund <andres@anarazel.de> wrote:
> I noticed that there is not a test case which would cover the speculative > wait > codepath. This seems much more challenging, however, it does seem like a > worthwhile test to have.
Shouldn't be that hard to create, I think. I think acquiring another lock in a second, non-unique, expression index, ought to do the trick? It probably has to be created after the unique index (so it's later in the
I would think that the sequence would be s1 and s2 probe the index, s1 and s2 insert into the table, s1 updates the index but does not complete the speculative insert and clear the token (pause before table_complete_speculative). s2 is in speculative wait when attempting to update the index.
Something like
permutation "controller_locks" "controller_show" "s1_upsert" "s2_upsert" "controller_show" "controller_unlock_1_1" "controller_unlock_2_1" "controller_unlock_1_3" "controller_unlock_2_3" "controller_unlock_1_2" "s1_magically_pause_before_complete_speculative" # put s2 in speculative wait "controller_unlock_2_2" "s1_magically_unpause_before_complete_speculative"
So, how would another lock on another index keep s1 from clearing the speculative token after it has updated the index?
The second index would help to hold the session after inserting the tuple in unique index but before completing the speculative insert. Hence, helps to create the condition easily. I believe order of index insertion is helping here that unique index is inserted and then non-unique index is inserted too.
Attaching patch with the test using the idea Andres mentioned and it works to excercise the speculative wait.
