Re: Is this a memory leak in libpqrcv_processTuples()?

From: Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com>
To: Dewei Dai <daidewei1970(at)163(dot)com>
Cc: "li(dot)evan(dot)chao" <li(dot)evan(dot)chao(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Is this a memory leak in libpqrcv_processTuples()?
Date: 2026-01-07 08:22:50
Message-ID: CAA3qoJ=1CxTu+JMH3JvO7TJtT-AD+AB2myyKypTLoptgRQx1-g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Chao,

As you mentioned, attinmeta will be automatically freed when the memory
context is destroyed. If our concern here is that repeated calls to
walrcv_exec in some section of the code are causing a large number of
attinmeta objects to remain unreleased(I’m not sure if anyone would use
walrcv_exec to do something like this), this would seem to imply that we
are repeatedly constructing identical attinmeta instances – for example:

*while (loop_condition) { sprintf(query, "xxx where xx = %d", index++);
res = walrcv_exec(conn, query, ...);}*

It is rare to encounter a scenario where walrcv_exec is called multiple
times and each invocation uses a query with different attrs. Therefore, if
this loop scenario is indeed the case, should we consider avoiding the
repeated construction of tupdesc/attinmeta?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tushar 2026-01-07 08:22:58 Re: Non-text mode for pg_dumpall
Previous Message Chao Li 2026-01-07 08:14:38 Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)