> If that's a correct diagnosis, > we'll probably see this on other slow animals before too much longer.
This is the correct diagnosis.
+ q(select test_custom_stats_var_update(name)
+ from (values ('entry1', 2), ('entry2', 3),
+ ('entry3', 2), ('entry4', 3)) as stats(name, n),
+ generate_series(1, n)));
These entry updates are batched now, which was not done before. This
leaves them as pending stats in the updating backend, and the next
safe_psql() runs in a different backend and checks the values before
the updating backend has finished shutdown and flushed its pending stats.
To confirm, I tested by slowing down pgstat_shutdown_hook(), and I was
able to reproduce similar failures.
+++ b/src/backend/utils/activity/pgstat.c
@@ -658,6 +658,9 @@ pgstat_shutdown_hook(int code, Datum arg)
if (OidIsValid(MyDatabaseId))
pgstat_report_disconnect(MyDatabaseId);
+ if (!dlist_is_empty(&pgStatPending))
+ pg_usleep(1000000L);
+
pgstat_report_stat(true);
We need to force a flush when test_custom_stats_var_update(), which calls
pgstat_prep_pending_entry(), is followed by test_custom_stats_var_report()
from another backend. This is only the case for the batched updates.
--
Sami
v1-0001-pgstat-Stabilize-test_custom_stats-counter-checks.patch
Description: Binary data
