On Tue, Sep 23, 2025 at 01:39:00PM -0500, Sami Imseih wrote: > The refcount reaches 0 when all backends release their references to the > stat, so if something like pg_stat_statements relies on a count for > deallocation purposes (to stay within the max), and that value only > decrements when all references are released, then it could end up > constantly triggering deallocation attempts. So, I am wondering if we > actually need another value that tracks "live" entries, or those that > have not yet been marked for drop. This means the live entries count > is decremented as soon as the entry is set to ->dropped.
Couldn't that mean a potential bloat in terms of memory in the dshash if we have a large cycle of objects still held around but marked to be gone? That sounds risky to me as it could go out of control. The counter tracking exactly the number of dshash entries would provide a tighter control, and perhaps this would be OK if the actual deallocations are grouped. Your suggestion would not be difficult to implement, as well, requiring an extra tweak when entries are reused, and that's handled in a unique path. > As a side note, maybe I am missing something here: > In [0], should this not say ".... the entry should not be freed" instead of > ".... the entry should not be dropped". The refcount deals with the freeing > of the entry after all refs are released. > > [0] > https://github.com/postgres/postgres/blob/f2bae51dfd5b2edc460c86071c577a45a1acbfd7/src/include/utils/pgstat_internal.h#L98-L99 The sentence looks correct to me? The refcount cannot be incremented if an entry is marked for drop, as far as I recall. -- Michael
signature.asc
Description: PGP signature
