Alvaro Herrera writes:
> On 2023-Apr-24, Tom Lane wrote:
>> I guess we could have the back branches continue to create a
>> shared_cast_context and just not use it in core. Seems rather
>> expensive for a very hypothetical compatibility measure, though.
> I think a session-long memory leak is no
On 2023-Apr-24, Tom Lane wrote:
> I wrote:
> > Alvaro Herrera writes:
> >> Hmm, we can leave it unused in our code, but it still needs to be
> >> initialized to some valid memory context anyway; otherwise hypothetical
> >> code that uses it would still crash.
>
> > I think we want that to happen
I wrote:
> Alvaro Herrera writes:
>> Hmm, we can leave it unused in our code, but it still needs to be
>> initialized to some valid memory context anyway; otherwise hypothetical
>> code that uses it would still crash.
> I think we want that to happen, actually, because it's impossible
> to guess
Alvaro Herrera writes:
>> (Note to self: we can't remove the cast_hash_context field in
>> back branches for fear of causing an ABI break for pldebugger.
>> But we can leave it unused, I think.)
> Hmm, we can leave it unused in our code, but it still needs to be
> initialized to some valid memory
On 2023-Apr-21, Tom Lane wrote:
> (Note to self: we can't remove the cast_hash_context field in
> back branches for fear of causing an ABI break for pldebugger.
> But we can leave it unused, I think.)
Hmm, we can leave it unused in our code, but it still needs to be
initialized to some valid memo
Tom, Thanks a lot for your patch. I applied the changes and confirmed
there is no memory leak with the V2 patch.
We are not using MemoryContext variables "cast_hash_context" and
"shared_cast_context".
Thanks & Best Regards,
Ajit
On Sat, Apr 22, 2023 at 4:49 AM Tom Lane wrote:
> Ajit Awekar wr
Ajit Awekar writes:
> I have implemented the approach by splitting the hash table into two parts.
> Please find the attached patch for the same.
I found a few things not to like about this:
* You didn't update the comment describing these hash tables.
* I wasn't really thrilled about renaming t
Hi Tom,
Thanks a lot for your possible approach for a solution.
I have implemented the approach by splitting the hash table into two parts.
Please find the attached patch for the same.
Thanks & Best Regards,
Ajit
On Wed, Apr 19, 2023 at 10:13 PM Tom Lane wrote:
> Ajit Awekar writes:
> > Plea
Ajit Awekar writes:
> Please find below simple repro for CacheMemoryContext memory leak
Hm, yeah, reproduced here.
> During anonymous block execution in the function "plpgsql_estate_setup", a
> local casting hash table gets created in SPI memory context. When hash
> table look up is performed in
Please find below simple repro for CacheMemoryContext memory leak
create type two_int4s as (f1 int4, f2 int4);
create type two_int8s as (q1 int8, q2 int8);
PLpgSQL example:
do $$ declare c4 two_int4s; c8 two_int8s;
begin
c8 := row(1,2);
c4 := c8;
end$$;
Executing above plpgsql in same memory
10 matches
Mail list logo
