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/张 杰 <zhangj...@cn.fujitsu.com>; Matsumura, Ryo/松村 量 <matsumura....@jp.fujitsu.com>; 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 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
