> > As far as I can see, the current implementation does not apply any
> > throttling to calls of this API. In theory, a large number of backends
> > could invoke it frequently and generate a high flush rate. For
> > example, if 1000 backends were to call it once per second, that would
> > result in 1000 shared-stats updates per second.
> >
> > Whether such a usage pattern would occur in practice is a separate
> > question. However, given that existing pgstat code uses
> > PGSTAT_MIN_INTERVAL to limit flush frequency, it seems to me that
> > anytime stats should probably retain a similar restriction.
>
> Hmm, OK. One cost in this decision is that it could randomly make the
> tests randomly slower, which is one reason why this patch has been
> added to this thread.
The throttling does make the tests longer, but we can do similar to what
was done in f1e251be80a, and disable PGSTAT_MIN_INTERVAL if
injection points are enabled.
- /* 50 tries with 100ms sleep between tries makes 5 sec total wait */
- for (tries = 0; tries < 50; tries++)
+ /*
+ * Retry up to 50 times with 100ms between attempts (max 5s
total). Can be
+ * reduced to 3 attempts (max 0.3s total) to speed up tests.
+ */
+ int ntries = 50;
+
+#ifdef USE_INJECTION_POINTS
+ if (IS_INJECTION_POINT_ATTACHED("procarray-reduce-count"))
+ ntries = 3;
+#endif
+
--
Sami Imseih
Amazon Web Services (AWS)
