Re: Adding a test for speculative insert abort case

On Wed, May 15, 2019 at 8:36 PM Melanie Plageman <melanieplageman@gmail.com>
wrote:

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