| 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?
| 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) |