Dear Meskes, Zhang,
I think this modification is not enough, and I have an another idea.
>> If your patch is committed, in your example, any operation for cur1 will not
>> be accepted.
> Although the return value after calling ecpg_get_con_name_by_cursor_name(cur1)
> is NULL, in
Hi,
> Memory leaks occur when the ecpg_update_declare_statement() is called
> the second time.
> ...
I'm going to commit this patch HEAD, this way we can see if it works as
advertised. It does not hurt if it gets removed by a rewrite.
Thanks for finding the issue,
Michael
--
Michael Meskes
, this problem will be easily solved.
How about it?
Hayato Kuroda
Fujitsu LIMITED
-Original Message-
From: Zhang, Jie/张 杰
Sent: Tuesday, June 11, 2019 5:14 PM
To: Kuroda, Hayato/�\田 隼人 ; Matsumura, Ryo/松村 量
; pgsql-hackers@lists.postgresql.org
Subject: RE: [PATCH] memory leak in ecpglib
Dear Zhang,
# I resend the email
Thank you for reporting a bug. I didn't care about this case.
>> We should free p->cursor_name before p->cursor_name =
>> ecpg_strdup(cursor_name, lineno).
I'm wondering whether this approach is correct or not.
If your patch is committed, in your example, any
l Message-
From: Kuroda, Hayato/�\田 隼人
Sent: Tuesday, June 11, 2019 2:36 PM
To: Zhang, Jie/张 杰 ; Matsumura, Ryo/松村 量
; pgsql-hackers@lists.postgresql.org
Subject: RE: [PATCH] memory leak in ecpglib
Dear Zhang,
# I resend the email
Thank you for reporting a bug. I didn't care about this case
Jie/张 杰 ;
pgsql-hackers@lists.postgresql.org
Cc: Zhang, Jie/张 杰
Subject: RE: [PATCH] memory leak in ecpglib
Hi
On Mon. June. 10, 2019 at 09:54 AM Zhang, Jie < zhangj...@cn.fujitsu.com >
wrote:
>
> Memory leaks occur when the ecpg_update_declare_statement() is called
> the secon
Hi
On Mon. June. 10, 2019 at 09:54 AM Zhang, Jie
< zhangj...@cn.fujitsu.com > wrote:
>
> Memory leaks occur when the ecpg_update_declare_statement() is called the
> second time.
Certainly it is.
But I wonder if it is safe that the old cursor_name is forgotten.
Regards
Ryo Matsumura
>
