On Wed, Sep 2, 2026 at 11:27 AM David Geier <[email protected]> wrote:
> >>> I chose to keep an accurate running count of the memory footprint per > >>> backend by tracking both the sizeof(Vfd) and the exact filename string > >>> lengths. > >>> > >>> We add the string length to the total footprint when a file is opened, > >> and > >>> subtract it when the VFD is freed (i suppose this is not "Too much" of > a > >>> work done, although it's done in a bit hot place); v5 of the patch is > >>> attached. > >> Better use GetMemoryChunkSpace() instead of using strlen() + 1, to get > >> the true allocation size. > >> > > That wouldn't work because filename is malloc'd and not palloc'd, which > is > > what GetMemoryChunkSpace() works on IIUC. > > Am i correct here? > That's interesting an interesting realization. You're right that we > cannot use GetMemoryChunkSpace() in that case. > > However, I'm wondering if the better approach wouldn't be to change fd.c > to use a long-lived memory context. Then all bookkeeping would happen > automatically and the memory size could simply be reported via existing > memory context stats infrastructure. > > Not entirely sure though if there's some roadblock when switching to a > memory context. I don't see any issue with this either. However, the only benefit we would gain is using existing infrastructure but only for backend vfd cache memory (i.e cache_bytes). Everything else stays the same (counters, cluster-wide memory); therefore, if there's no other benefit to replacing with memory contexts, maybe it's not worth it. Regards, Ayoub
