Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash

> 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