Re: missing PG_FREE_IF_COPY in textlike() and textnlike() ?

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

In response to

Browse pgsql-hackers by date

  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