On Fri, 14 Jul 2023 at 07:57, Michael Paquier wrote:
>
> On Thu, Jul 13, 2023 at 06:28:39PM +0200, Matthias van de Meent wrote:
> > There are similar pfree calls in the _int_gist.c file's g_int_compress
> > function, which made me think we do need to clean up after use, but
> > indeed these pfrees
On Thu, Jul 13, 2023 at 06:28:39PM +0200, Matthias van de Meent wrote:
> There are similar pfree calls in the _int_gist.c file's g_int_compress
> function, which made me think we do need to clean up after use, but
> indeed these pfrees are useless (or even harmful if bug #17888 can be
> trusted)
I
On Thu, 13 Jul 2023 at 17:20, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > My collegue Konstantin (cc-ed) noticed that the GiST code of intarray
> > may leak memory in certain index operations:
>
> Can you demonstrate an actual problem here, that is a query-lifespan leak?
>
> IMO, the co
I wrote:
> Matthias van de Meent writes:
>> My collegue Konstantin (cc-ed) noticed that the GiST code of intarray
>> may leak memory in certain index operations:
> Can you demonstrate an actual problem here, that is a query-lifespan leak?
> IMO, the coding rule in the GiST and GIN AMs is that th
Matthias van de Meent writes:
> My collegue Konstantin (cc-ed) noticed that the GiST code of intarray
> may leak memory in certain index operations:
Can you demonstrate an actual problem here, that is a query-lifespan leak?
IMO, the coding rule in the GiST and GIN AMs is that the AM code is
resp
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);
