- Notifications
You must be signed in to change notification settings - Fork5
Commit47215c1
committed
Avoid useless closely-spaced writes of statistics files.
The original intent in the stats collector was that we should not write outstats data oftener than every PGSTAT_STAT_INTERVAL msec. Backends will notmake requests at all if they see the existing data is newer than that, andthe stats collector is supposed to disregard requests having a cutoff_timeolder than its most recently written data, so that close-together requestsdon't result in multiple writes. But the latter part of that got brokenin commit187492b, so that if two backends concurrently decidethe existing stats are too old, the collector would write the data twice.(In principle the collector's logic would still merge requests as long asthe second one arrives before we've actually written data ... but sincethe message collection loop would write data immediately after processinga single inquiry message, that never happened in practice, and in any casethe window in which it might work would be much shorter thanPGSTAT_STAT_INTERVAL.)To fix, improve pgstat_recv_inquiry so that it checks whether the cutofftime is too old, and doesn't add a request to the queue if so. This meansthat we do not need DBWriteRequest.request_time, because the decision istaken before making a queue entry. And that means that we don't reallyneed the DBWriteRequest data structure at all; an OID list of databaseOIDs will serve and allow removal of some rather verbose and crufty code.In passing, improve the comments in this area, which have been ratherneglected. Also change backend_read_statsfile so that it's not silentlyrelying on MyDatabaseId to have some particular value in the autovacuumlauncher process. It accidentally worked as desired because MyDatabaseIdis zero in that process; but that does not seem like a dependency we want,especially with no documentation about it.Although this patch is mine, it turns out I'd rediscovered a known bug,for which Tomas Vondra had already submitted a patch that's functionallyequivalent to the non-cosmetic aspects of this patch. Thanks to Tomasfor reviewing this version.Back-patch to 9.3 where the bug was introduced.Prior-Discussion: <1718942738eb65c8407fcd864883f4c8@fuzzy.cz>Patch: <4625.1464202586@sss.pgh.pa.us>1 parentad829c3 commit47215c1