Hi,
On 2019-10-04 14:43:00 -0700, Andres Freund wrote:
> > I think there's a good case to be made to backpatch the tests further
> > than 12, but I'm not sure about it? They do pass (with one error message
> > about a failure to delete changed to a failure to update, we didn't use
> > to be able to discern) back to 9.6, requiring
>
> I did push the tests back to 9.6.
There's a few ordering violations in the tests, e.g.:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2019-10-04%2021%3A51%3A13
key-a val-a-s1-ups1-ups1
step s1_c: COMMIT;
-s3: NOTICE: upd: text key-a = text key-a: t
-s3: NOTICE: upk: text val-a-s1-ups1-ups1 <> text mismatch: t
-s3: NOTICE: trigger: name rep_b_u; when: BEFORE; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new:
(key-a,val-a-s1-ups1-ups1-ups3)
-s3: NOTICE: trigger: name rep_a_u; when: AFTER; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new:
(key-a,val-a-s1-ups1-ups1-ups3)
-step s3_upd_a_data: <... completed>
+s2: NOTICE: upd: text key-a = text key-a: t
+s2: NOTICE: upk: text val-a-s1-ups1-ups1 <> text mismatch: t
+s2: NOTICE: trigger: name rep_b_u; when: BEFORE; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new:
(key-a,val-a-s1-ups1-ups1-upserts2)
+s2: NOTICE: trigger: name rep_a_u; when: AFTER; lev: ROWs; op: UPDATE; old: (key-a,val-a-s1-ups1-ups1) new:
(key-a,val-a-s1-ups1-ups1-upserts2)
+step s2_upsert_a_data: <... completed>
key data
I was under the assumption that it'd be deterministic who gets to
continue with a speculative insertion, but that ain't so.
Peter, do you see an easy way around that? Do you consider that a
problem? ISTM we ought to make this fair, but that doing so would
require a bit bigger changes that we'd want to make in the backbranches?
Unless somebody comes up with an idea, I'll disable (or rewrite) the
"three way" tests involving two waiters for one insertion.
Regards,
Andres