Horton

Potential memory leak in contrib/intarray's g_intbig_compress

Matthias van de Meent <boekewurm+postgres@gmail.com>

View thread View on postgr.es
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Konstantin Knizhnik <knizhnik@garret.ru>
Date: 2023-07-13T12:02:36Z
Lists: pgsql-hackers

Attachments

Hi,

My collegue Konstantin (cc-ed) noticed that the GiST code of intarray
may leak memory in certain index operations:

> g_intbig_compress(...):
> [...]
>         ArrayType  *in = DatumGetArrayTypeP(entry->key);
> [...]
>         if (in != DatumGetArrayTypeP(entry->key))
>             pfree(in);

DatumGetArrayTypeP will allocate a new, uncompressed copy if the given
Datum is compressed. So in this code, if entry->key is compressed we'd
allocate two decompressed copies, while only we only deallocate the
first of these two. I believe the attached patch fixes the issue.

It looks like this bug has existed since the code was first committed,
so backpatching would go back to 11 if this is an active issue.

Kind regards,

Matthias van de Meent

Commits

  1. Remove unnecessary pfree() in g_intbig_compress().