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

> > FWIW, I am not convinced that the gain in coverage is worth the cycles
> > on this one. This is only one WARNING with many more patterns to
> > check how pgstat_read_statsfile() is robust with changes in
> > shared_preload_libraries and reuses of the same IDs.
>
> I agree, I included the test mainly because it's an easy reproducer
> for the issue, otherwise it's very specific. I only kept it as a
> single patch because the entire thing is small and it is easy to
> separate the pgstat.c changes from it.

Not including the test is fine by me. Coverage of pgstat startup is
thin overall,
and a test for this one case doesn't get us much closer to covering the many
ways the stats file can go bad.

> But if we just added a set of SQL functions able to read
> or edit a stats file and began publishing pgstat_read_statsfile() or
> an equivalent of it, it would be a different story. Whether it is
> worth having or not is a different story.

Right, I think that would be the better way to get coverage here.
Low priority, but nice to have.

Attached v2 removes the test from 0002; the pgstat.c fix and
0001 are unchanged.

--
Sami