Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit60690a6

Browse files
committed
Make stats regression test robust in the face of parallel query.
Historically, the wait_for_stats() function in this test has simply checkedfor a report of an indexscan on tenk2, corresponding to the last commandissued before we expect stats updates to appear. However, with parallelquery that indexscan could be done by a parallel worker that will emitits stats counters to the collector before the session's main backend does(a full second before, in fact, thanks to the "pg_sleep(1.0)" added bycommit957d08c). That leaves a sizable window in which anautovacuum-triggered write of the stats files would present a state inwhich the indexscan on tenk2 appears to have been done, but none of thewrite updates performed by the test have been. This is evidently theexplanation for intermittent failures seen by me and on buildfarm membermandrill.To fix, we should check separately for both the tenk2 seqscan and indexscancounts, since those might be reported by different processes that could bedelayed arbitrarily on an overloaded test machine. And we need to checkfor at least one update-related count. If we ever allow parallel workersto do writes, this will get even more complicated ... but in view of allthe other hard problems that will entail, I don't feel a need to solve thisone today.Per research by Rahila Syed and myself; part of this patch is Rahila's.
1 parent708020e commit60690a6

File tree

2 files changed

+40
-8
lines changed

2 files changed

+40
-8
lines changed

‎src/test/regress/expected/stats.out

Lines changed: 20 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -37,17 +37,33 @@ SELECT t.seq_scan, t.seq_tup_read, t.idx_scan, t.idx_tup_fetch,
3737
create function wait_for_stats() returns void as $$
3838
declare
3939
start_time timestamptz := clock_timestamp();
40-
updated bool;
40+
updated1 bool;
41+
updated2 bool;
42+
updated3 bool;
4143
begin
4244
-- we don't want to wait forever; loop will exit after 30 seconds
4345
for i in 1 .. 300 loop
4446

47+
-- With parallel query, the seqscan and indexscan on tenk2 might be done
48+
-- in parallel worker processes, which will send their stats counters
49+
-- asynchronously to what our own session does. So we must check for
50+
-- those counts to be registered separately from the update counts.
51+
52+
-- check to see if seqscan has been sensed
53+
SELECT (st.seq_scan >= pr.seq_scan + 1) INTO updated1
54+
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
55+
WHERE st.relname='tenk2' AND cl.relname='tenk2';
56+
4557
-- check to see if indexscan has been sensed
46-
SELECT (st.idx_scan >= pr.idx_scan + 1) INTOupdated
58+
SELECT (st.idx_scan >= pr.idx_scan + 1) INTOupdated2
4759
FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr
4860
WHERE st.relname='tenk2' AND cl.relname='tenk2';
4961

50-
exit when updated;
62+
-- check to see if updates have been sensed
63+
SELECT (n_tup_ins > 0) INTO updated3
64+
FROM pg_stat_user_tables WHERE relname='trunc_stats_test';
65+
66+
exit when updated1 and updated2 and updated3;
5167

5268
-- wait a little
5369
perform pg_sleep(0.1);
@@ -127,7 +143,7 @@ SELECT count(*) FROM tenk2 WHERE unique1 = 1;
127143
1
128144
(1 row)
129145

130-
-- force the rate-limiting logic inpgstat_report_tabstat() to time out
146+
-- force the rate-limiting logic inpgstat_report_stat() to time out
131147
-- and send a message
132148
SELECT pg_sleep(1.0);
133149
pg_sleep

‎src/test/regress/sql/stats.sql

Lines changed: 20 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -32,17 +32,33 @@ SELECT t.seq_scan, t.seq_tup_read, t.idx_scan, t.idx_tup_fetch,
3232
createfunctionwait_for_stats() returns voidas $$
3333
declare
3434
start_timetimestamptz := clock_timestamp();
35-
updated bool;
35+
updated1 bool;
36+
updated2 bool;
37+
updated3 bool;
3638
begin
3739
-- we don't want to wait forever; loop will exit after 30 seconds
3840
for iin1 ..300 loop
3941

42+
-- With parallel query, the seqscan and indexscan on tenk2 might be done
43+
-- in parallel worker processes, which will send their stats counters
44+
-- asynchronously to what our own session does. So we must check for
45+
-- those counts to be registered separately from the update counts.
46+
47+
-- check to see if seqscan has been sensed
48+
SELECT (st.seq_scan>=pr.seq_scan+1) INTO updated1
49+
FROM pg_stat_user_tablesAS st, pg_classAS cl, prevstatsAS pr
50+
WHEREst.relname='tenk2'ANDcl.relname='tenk2';
51+
4052
-- check to see if indexscan has been sensed
41-
SELECT (st.idx_scan>=pr.idx_scan+1) INTOupdated
53+
SELECT (st.idx_scan>=pr.idx_scan+1) INTOupdated2
4254
FROM pg_stat_user_tablesAS st, pg_classAS cl, prevstatsAS pr
4355
WHEREst.relname='tenk2'ANDcl.relname='tenk2';
4456

45-
exit when updated;
57+
-- check to see if updates have been sensed
58+
SELECT (n_tup_ins>0) INTO updated3
59+
FROM pg_stat_user_tablesWHERE relname='trunc_stats_test';
60+
61+
exit when updated1and updated2and updated3;
4662

4763
-- wait a little
4864
perform pg_sleep(0.1);
@@ -121,7 +137,7 @@ SELECT count(*) FROM tenk2;
121137
-- do an indexscan
122138
SELECTcount(*)FROM tenk2WHERE unique1=1;
123139

124-
-- force the rate-limiting logic inpgstat_report_tabstat() to time out
140+
-- force the rate-limiting logic inpgstat_report_stat() to time out
125141
-- and send a message
126142
SELECT pg_sleep(1.0);
127143

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp