From: | CK Tan <cktan(at)vitessedata(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: missing PG_FREE_IF_COPY in textlike() and textnlike() ? |
Date: | 2022-09-16 07:29:15 |
Message-ID: | CAJNt7=bU=awNyp3+C=Wv=zswAnu5e-HfnTFsNYH+kc1NTU9Xug@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Got it. It is a leak-by-design for efficiency.
Thanks,
-cktan
On Fri, Sep 16, 2022 at 12:03 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> CK Tan <cktan(at)vitessedata(dot)com> writes:
> > I see in the texteq() function calls to DatumGetTextPP() are followed
> > by conditional calls to PG_FREE_IF_COPY. e.g.
>
> That's because texteq() is potentially usable as a btree index
> function, and btree isn't too forgiving about leaks.
>
> > However, in textlike(), PG_FREE_IF_COPY calls are missing.
> > https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/like.c#L283
>
> textlike() isn't a member of any btree opclass.
>
> > Is this a memory leak bug?
>
> Not unless you can demonstrate a case where it causes problems.
> For the most part, such functions run in short-lived contexts.
>
> regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-09-16 07:29:32 | Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans |
Previous Message | Zhang Mingli | 2022-09-16 07:16:41 | Re: Remove dead macro exec_subplan_get_plan |