RE: [PATCH] memory leak in ecpglib
От | kuroda.hayato@fujitsu.com |
---|---|
Тема | RE: [PATCH] memory leak in ecpglib |
Дата | |
Msg-id | TYAPR01MB4749A2E4572A3CE1B0A28508F5F60@TYAPR01MB4749.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: [PATCH] memory leak in ecpglib (Michael Meskes <meskes@postgresql.org>) |
Список | pgsql-hackers |
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 ecpg_get_connection(), actual_connection will be returned. > so, operation for cur1 will be accepted, Did you mention about this code? (Copied from ECPGfetch) ``` real_connection_name = ecpg_get_con_name_by_cursor_name(cursor_name); if (real_connection_name == NULL) { /* * If can't get the connection name by cursor name then using * connection name coming from the parameter connection_name */ real_connection_name = connection_name; } ``` If so, I think this approach is wrong. This connection_name corresponds to the following con1. ``` EXEC SQL AT con1 FETCH cur1 ... ^^^^ ``` Therefore the followed FETCH statement will fail because the application forget the connection of cur_1. ``` EXEC SQL AT con1 DECLARE stmt_1 STATEMENT; EXEC SQL PREPARE stmt_1 FROM :selectString; EXEC SQL DECLARE cur_1 CURSOR FOR stmt_1; EXEC SQL OPEN cur_1; EXEC SQL DECLARE cur_2 CURSOR FOR stmt_1; EXEC SQL OPEN cur_2; EXEC SQL FETCH cur_1; ``` I think the g_declared_list is not needed for managing connection. I was wrong. We should treat DECLARE STAEMENT as declarative, like #include or #define in C macro. Please send me your reply. Best Regards, Hayato Kuroda Fujitsu LIMITED
В списке pgsql-hackers по дате отправления: