Re: pgstat: Flush some statistics within running transactions, take 2

Hi,

> Yeah, that would address my concern and keep memcmp(), so +1.

Thanks. I went ahead and did that in v8-0002 (previously v7-0001).

On top of the txn and non-txn stats split, that patch now moves truncdropped
out of the counter struct and into PgStat_RelationStatus, and adds
StaticAssertDecl
checks so the txn and no-txn counter structs contain only
PgStat_Counter fields with
no padding. That keeps the memcmp() safe and we can avoid doing
field-by-field comparisons. All these changes are kept in one patch as they all
serve the purpose of providing safe memcmp() for the stats.

> If pgstat_prep_database_pending() errors, the shared index (or
> relation) stats have already been updated, while the database stats
> and flushed baseline have not.
>
> I wonder if pgstat_prep_database_pending() should be called before
> the first shared stat update, or if the callback should ensure that
> an error cannot leave the flush partially applied?

That issue is already present in HEAD and is not introduced by this
patch set. pgstat_prep_database_pending() can already ERROR on OOM while
setting up the database pending entry, so this is not new here.

That said, preparing the database pending entry before updating any
stats is probably a better idea just for consistency during such cases,
so I split that out as a standalone fix in v8-0001.

For v8-0003, most of the visible churn comes from splitting out
v8-0001 and v8-0002. Other differences are the custom stats example and
related test updates, plus a few extra padding checks for memcmp() in
flush callbacks. I also removed the pgstat_reset_entry() custom stats
example for now to keep things simple.

--
Sami Imseih
Amazon Web Services (AWS)