Did 10.1 also exist holding temp free problem ?

[xie_jiong]

Hi All,

I found that SELECT / UPDATE lob column which has holding temp creating involved still has memery problems in 10.1 version. For example:

select long_varchar(name) from aa; --name is a varchar column

For every row in aa, the dbms will create a new holding temp table to hold convered name value, and then in the adu_redeem to get value from that holding temp, BUT I found that the system will not delete the holding temp, so row after row, many holding temps will accumulate until end of selection the dmpe_free_temps frees all temps. But if aa has many many rows , it will use up memetry resource before end of selection!

Any idea?

Jiong

[kschendel]

Hi Jiong,
Yes, this is a problem. In the 10s (spatial) release, we made a change to allow more than one temporary lob value per holding temp if too many holding temps are being created. That is not an ideal solution but it's workable. I don't know if that change is in any of the public source code releases, since I've lost track of what is being released and what isn't.

Karl

[xie_jiong]

Thanks Karl, But will the 'add but not create' solution avoids the memory problem? If one temp table becomes larger and larger, the memory problem also exists I think. Are there any garbage collection involved?

We add the free holding temp in adu_redeem as follows:

....
case ADW_GET_DATA:
...
if (work->adw_fip.fip_pop_cb.pop_error.err_code
== E_AD7001_ADP_NONEXT)
{
work->adw_fip.fip_done = TRUE;

if (status == E_DB_WARN)
status = E_DB_OK;
else
break;

/* new code begin. the premise is pop_temporary set up correct /*
if(work->adw_fip.fip_pop_cb.pop_temporary == ADP_POP_TEMPORARY)
{
status =(*Adf_globs->Adi_fexi[ADI_01PERIPH_FEXI].adi_fcn_fexi)
(ADP_DELETE, &work->adw_fip.fip_pop_cb);
if (status != E_DB_OK)
break;
}

...

It worked, but we don't know its side effect.

Jiong

[kschendel]

It's probably OK to free the temp after a redeem, I don't imagine it would get used again. Most of the problems with freeing LOB temps earlier are related to temp value re-use: either in DB procedures, or in an UPDATE statement, or because of something that the query compiler (opc) did.

Multiple values per LOB holding temp does reduce memory usage because you don't need the added temp table TCB, RCB, name-reservation lock, etc.

[xie_jiong]

Thanks Karl. We hope the Multiple values per LOB holding temp could open source...