Commit
60690a6fe attempted to fix the wait_for_stats() function in this
test so that it would wait properly if the tenk2 scans were done in
parallel workers instead of the main session (typically as a consequence of
force_parallel_mode being turned on). However, we made it test for whether
the main session's actions had been reported by looking for inserts on
'trunc_stats_test'. This is the Wrong Thing, because those aren't the last
updates we expect the main session to do. As shown by recent failures on
buildfarm member frogmouth, it's entirely likely that the trunc_stats_test
updates will be reported in a separate message from later updates, which
means there can be a window in which wait_for_stats() will exit but not all
the updates we are expecting to see will have arrived. We should test for
the last updates we're expecting, namely those on 'trunc_stats_test4'.
Unfortunately, I doubt that this explains frogmouth's failures, because
there's no reason to believe that it's running the tenk2 queries in
parallel. Still, the test is wrong on its own terms, so fix and back-patch
to 9.6 where parallel query came in.
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
- -- check to see if updates have been sensed
+ -- check to see if all updates have been sensed
SELECT (n_tup_ins > 0) INTO updated3
- FROM pg_stat_user_tables WHERE relname='trunc_stats_test';
+ FROM pg_stat_user_tables WHERE relname='trunc_stats_test4';
exit when updated1 and updated2 and updated3;
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
WHERE st.relname='tenk2' AND cl.relname='tenk2';
- -- check to see if updates have been sensed
+ -- check to see if all updates have been sensed
SELECT (n_tup_ins > 0) INTO updated3
- FROM pg_stat_user_tables WHERE relname='trunc_stats_test';
+ FROM pg_stat_user_tables WHERE relname='trunc_stats_test4';
exit when updated1 and updated2 and updated3;