[PATCH] Free BufFile metadata in close and append paths

  • Jump to comment-1
    DaeMyung Kang<charsyam@gmail.com>
    Apr 29, 2026, 3:47 PM UTC
    Hi, Hackers,
    Continuing the storage/file audit, I found two small but consistent
    metadata leaks in BufFile. BufFileClose() does not release the
    pstrdup'd name on FileSet-based BufFiles, and BufFileAppend()
    silently retains the source wrapper (including its BLCKSZ buffer)
    even though the function semantics already say the source must not
    be touched after the call.
    Details and the parallel-sort motivation are in the commit message.
    Thanks,
    DaeMyung
    ---
    FileSet-based BufFiles duplicate their logical name, but BufFileClose()
    did not release it. Release that metadata along with the other
    palloc'd state owned by the BufFile.
    BufFileAppend() transfers only the underlying file handles to the
    target while telling callers not to use the source again. Free the
    consumed source wrapper and metadata after the transfer so repeated
    appends do not retain a BLCKSZ-sized BufFile wrapper until context
    reset.
    This matters most for parallel sort workflows that issue many
    BufFileAppend() calls in a single context: each retained source
    wrapper holds a BLCKSZ-sized buffer until context reset, which can
    run into hundreds of KB at high DOP.
    ---
     src/backend/storage/file/buffile.c | 22 +++++++++++++++++-----
    1 file changed, 17 insertions(+), 5 deletions(-)