RE: [PATCH] memory leak in ecpglib

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

In response to

Browse pgsql-hackers by date

  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