Re: missing PG_FREE_IF_COPY in textlike() and textnlike() ? - Mailing list pgsql-hackers

From CK Tan
Subject Re: missing PG_FREE_IF_COPY in textlike() and textnlike() ?
Date
Msg-id CAJNt7=bU=awNyp3+C=Wv=zswAnu5e-HfnTFsNYH+kc1NTU9Xug@mail.gmail.com
Whole thread Raw
In response to Re: missing PG_FREE_IF_COPY in textlike() and textnlike() ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@sss.pgh.pa.us> wrote:
>
> CK Tan <cktan@vitessedata.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



pgsql-hackers by date:

Previous
From: Zhang Mingli
Date:
Subject: Re: Remove dead macro exec_subplan_get_plan
Next
From: Masahiko Sawada
Date:
Subject: Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans