From: | "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'Michael Meskes' <meskes(at)postgresql(dot)org>, "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-07-08 08:27:52 |
Message-ID: | TYAPR01MB4749A2E4572A3CE1B0A28508F5F60@TYAPR01MB4749.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2019-07-08 08:52:20 | Re: Excessive memory usage in multi-statement queries w/ partitioning |
Previous Message | Pavel Stehule | 2019-07-08 08:22:52 | Re: dropdb --force |