Re: Add pg_stat_vfdcache view for VFD cache statistics

On Wed, Sep 2, 2026 at 11:27 AM David Geier <geidav(dot)pg(at)gmail(dot)com> 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