RE: [doc fix] Add operation of freeing output SQLDA - Mailing list pgsql-hackers

From Kato, Sho
Subject RE: [doc fix] Add operation of freeing output SQLDA
Date
Msg-id 25C1C6B2E7BE044889E4FE8643A58BA963A45441@G01JPEXMBKW03
Whole thread Raw
In response to Re: [doc fix] Add operation of freeing output SQLDA  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Thank you for your reply.

>I didn't look it closer but generally speaking output sqlda should be freed automatically (or by ecpg API) since users
don'tknow it in detail.  
 

I think output sqlda should automatically.
But, it is difficult, because ecpg does not know which output sqlda can be freed.

Since the cursor does not know which sqlda is used, it is not possible to automatically free the output sqlda when the
cursoris closed.
 
Probably it is the same at other timing.

>I think if output sqlda is not freed and finally orphaned after correct API usage, it should be fixed. I suppose that
EXECSQL DEALLOCATE DESCRIPTOR is responsible..
 

I think DEALLOCATE DESCRIPTOR is for named sql descriptor.
ecpglib manages the descriptor in the linked list.
When DEALLOCATE DESCRIPTOR is called, ecpglib seaches the linked list using the name of the descriptor as a key and
freethe descriptor.
 

So, simply DEALLOCATE DESCRIPTOR cannot be used for sqlda. 
If free is undesirable, how would you think to make an ecpg API for free?

regards,
-----Original Message-----
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp] 
Sent: Tuesday, May 22, 2018 10:51 AM
To: Kato, Sho/加藤 翔 <kato-sho@jp.fujitsu.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: [doc fix] Add operation of freeing output SQLDA

Hello.

At Fri, 18 May 2018 06:03:59 +0000, "Kato, Sho" <kato-sho@jp.fujitsu.com> wrote in
<25C1C6B2E7BE044889E4FE8643A58BA963A42097@G01JPEXMBKW03>
> Hello
> 
> I think it is better to add freeing operation of output SQLDA to the current PostgreSQL documentation.
> As far as I can see src/interfaces/ecpg/ecpglib/execute.c,
> if a previously existing sqlda is set to output SQLDA, then a 
> previously existing sqlda is freed.
> But, the new output SQLDA's memory space remain.

I didn't look it closer but generally speaking output sqlda should be freed automatically (or by ecpg API) since users
don'tknow it in detail. It is a linked list so just freeing the first one is not sufficient(*1). On the other hand ecpg
librarycannot free input sqlda since it doesn't know how it was provided. Thus I'm on the documentation side. I'm not
sureof the reason for freeing output sqlda explicitly in the test code, maybe it is to avoid valgrind complaint or such
like..

I think if output sqlda is not freed and finally orphaned after correct API usage, it should be fixed. I suppose that
EXECSQL DEALLOCATE DESCRIPTOR is responsible..
 

> ecpg regression test also free output SQLDA's memory space.
> The attached patch fixes the documentation.


*1: The test code knows the shape exactly so it can properly free
    them in proper way.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center






pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Memory unit GUC range checks
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: A Japanese-unfriendy error message contruction