RE: [PATCH] memory leak in ecpglib - Mailing list pgsql-hackers

From kuroda.hayato@fujitsu.com
Subject RE: [PATCH] memory leak in ecpglib
Date
Msg-id TYAPR01MB4749A2E4572A3CE1B0A28508F5F60@TYAPR01MB4749.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [PATCH] memory leak in ecpglib  (Michael Meskes <meskes@postgresql.org>)
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: dropdb --force
Next
From: Amit Langote
Date:
Subject: Re: Excessive memory usage in multi-statement queries w/ partitioning