> > 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
v2-0001-Disallow-serialized-name-callbacks-for-fixed-numb.patch
Description: Binary data
v2-0002-Fix-crash-at-startup-with-stats-file-entry-of-fix.patch
Description: Binary data
