From: | "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | "zhangjie2(at)cn(dot)fujitsu(dot)com" <zhangjie2(at)cn(dot)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: [PATCH] memory leak in ecpglib |
Date: | 2019-06-19 02:43:56 |
Message-ID: | OSAPR01MB2004667F22D51C36B6E4AB8FF5E50@OSAPR01MB2004.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Zhang,
Sorry for my late reply.
I'm now planning to refactor this functionality:
https://www.postgresql.org/message-id/OSAPR01MB20048298F882D25897C6AB23F5EF0@OSAPR01MB2004.jpnprd01.prod.outlook.com
If DECLARE STATEMENT and other related statements are enabled only preprocessing process, 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/\田 隼人 <kuroda(dot)hayato(at)fujitsu(dot)com>; Matsumura, Ryo/松村 量 <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>; pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: RE: [PATCH] memory leak in ecpglib
Hi Kuroda,
>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 ecpg_get_connection(), actual_connection will be returned.
so, operation for cur1 will be accepted,
>p = ecpg_find_declared_statement(declared_name);
>if (p && p->cursor_name == cursor_name)
>p->cursor_name = ecpg_strdup(cursor_name, lineno);
Because the initial value of p->cursor_name is NULL, p->cursor_name will never be updated.
Best Regards!
-----Original Message-----
From: Kuroda, Hayato/\田 隼人
Sent: Tuesday, June 11, 2019 2:36 PM
To: Zhang, Jie/张 杰 <zhangjie2(at)cn(dot)fujitsu(dot)com>; Matsumura, Ryo/松村 量 <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com>; pgsql-hackers(at)lists(dot)postgresql(dot)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 operation for cur1 will not be accepted.
My idea is changing ecpg_update_declare_statement() for permitting one-to-many relation between a declared name and cursors.
An example is as below:
p = ecpg_find_declared_statement(declared_name);
if (p && p->cursor_name == cursor_name)
p->cursor_name = ecpg_strdup(cursor_name, lineno);
Do you have any suggestions or comments for this?
Best Regards,
Hayato Kuroda
Fujitsu LIMITED
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-06-19 02:44:26 | Re: openssl valgrind failures on skink are due to openssl issue |
Previous Message | Michael Paquier | 2019-06-19 02:28:16 | Re: openssl valgrind failures on skink are due to openssl issue |