Hello, Michael!
Michael Paquier <michael@paquier.xyz>:
> Ah, OK. So you want to have one single command, still wait through
> two injection points inside it. I am wondering about one thing: do
> you really require that? Could it be simpler to have two
> permutations, each one of them using one wait point to check your two
> scenarios?
Good point, I reviewed all 4 types of permutations - and I was able to
reduce it to 1 of such type.
permutation
s3_start_create_index(s1_start_upsert, s2_start_upsert)
s1_start_upsert
s4_wakeup_define_index_before_set_valid
s2_start_upsert(s1_start_upsert)
s4_wakeup_s1_from_invalidate_catalog_snapshot
s4_wakeup_s2
s4_wakeup_s1 <---- here
In human words it like this:
permutation
s3 creates new index and hangs before marking it as valid
s1 starts UPSERT, caches arbiter indexes and hangs in
InvalidateCatalogSnapshot
s4 wakes up CREATE INDEX - new index now valid
concurrent upsert s2 is started and hangs just before insertion
s4 wakes up s1 - old update reads index definitions, goes throw
check_exclusion_or_unique_constraint and hangs before insertion
s4 wakes up s2 - concurrent upsert inserts new tuples and finishes
s4 wakes up s1 - initial upsert going to insert tuple and receives error
So, I have to hang/wake up s1 two times:
* once it cached old arbiters and before it read index definitions
* once it decides it is OK to do insertions
> But AFAIU injection_point's 'notice' is a totally different type of notice
> compared to RAISE NOTICE - so, isolation_tester just ignores it.
I was wrong here - it respects 'notice', I was using it in the wrong order.
This is NOT working (hangs)
permutation
s1_notice
s2_noop(s1_notice notices 1)
s2_next
But this is working:
permutation
s2_noop(s1_notice notices 1)
s1_notice
s2_next
So, it looks like option C ('notice+wait') feels like the simplest
solution for me.
Best regards,
Mikhail.
