Message-ID: <11d0df16-94b8-4223-87f7-2e84084a28af@gmail.com>
Date: Wed, 2 Sep 2026 11:27:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics
To: Ayoub Kazar <kazarayoub2004@gmail.com>
Cc: KAZAR Ayoub <ma_kazar@esi.dz>, Tomas Vondra <tomas@vondra.me>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
References: 
 <CA+K2RumP33Cpj--88E+rNADa8fzSBBiav=rvzyaMM=sYNaOkfA@mail.gmail.com>
 <CAKZiRmzs99+q55pgBJ0-RHxL-z=ZRD-22cGR2w9jscOyxY-vfA@mail.gmail.com>
 <c85907b2-1e91-47e3-82dc-dafda295ded4@gmail.com>
 <CA+K2Ru=WXpG1Sfx=_DQVn7ENZz6C_j-HxVJ1TmkEKowLVQcYwg@mail.gmail.com>
 <d305fd37-346b-4512-808e-5dd7968eb569@gmail.com>
 <CA+K2RuncGCW55b-XUe8gJGwdMSOgTFKG-uSCgbVDZ+HewiT5EQ@mail.gmail.com>
 <CA+K2RumDZ05pru3-YSZxe3Y==vO0hsahiweyvJw6QsjuGR5WsA@mail.gmail.com>
 <42776281-3603-4161-b47d-d4ffd2029e8c@vondra.me>
 <CA+K2RumSp-kTw_YHXs_qN_RLt6cWfFR=LMq9coLgu8eyGydpHQ@mail.gmail.com>
 <02cfc5e7-e152-4d2d-8b4b-e899d9901ed5@gmail.com>
 <CA+K2Ruk55=2fBftAMg3Y=--+6uSNF05UVmu8w8S8FdJ+ektQcg@mail.gmail.com>
 <c94c385a-cdf6-44c5-9768-b8c47ab75868@gmail.com>
 <CADu+CpTwQXRdoKVSnoVRLp5m0UbA_cAU6s+_Og5=hCwKp0JR2Q@mail.gmail.com>
 <52677fc8-f57d-48c2-9415-6beb3ea6fa01@gmail.com>
 <CADu+CpSyR3fnHGwTRAbULyBtxPZbkR2Y41Dd36ombAUwG4TT3g@mail.gmail.com>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: 
 <CADu+CpSyR3fnHGwTRAbULyBtxPZbkR2Y41Dd36ombAUwG4TT3g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/11d0df16-94b8-4223-87f7-2e84084a28af%40gmail.com>
Precedence: bulk

>>> 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.

--
David Geier