PortalHeapMemoryFree...in diskless client

Karla Peralta <karlaper@elrosado.com> writes:

PostgreSQL version : 7.0.2-2

I startup my program in the client and sometimes a get this :

Notice: Begin already a transaction in progress
Notice: BlankPortalAssignName: portal myportal already exists
Notice: PortalHeapMemoryFree: 0x0x822bbf8 not in alloc set !

A bug with symptoms similar to this was fixed in 7.0.3. Please
try 7.0.3, and let us know if you still have problems.

regards, tom lane

Tom Lane wrote:

Karla Peralta <karlaper@elrosado.com> writes:

PostgreSQL version : 7.0.2-2

I startup my program in the client and sometimes a get this :

Notice: Begin already a transaction in progress
Notice: BlankPortalAssignName: portal myportal already exists
Notice: PortalHeapMemoryFree: 0x0x822bbf8 not in alloc set !

A bug with symptoms similar to this was fixed in 7.0.3. Please
try 7.0.3, and let us know if you still have problems.

regards, tom lane

Now I'm using postgresql-7.0.3-2 but I have the same problem.

What else can i do ????

Tom Lane wrote:

Karla Peralta <karlaper@elrosado.com> writes:

A bug with symptoms similar to this was fixed in 7.0.3. Please
try 7.0.3, and let us know if you still have problems.

Now I'm using postgresql-7.0.3-2 but I have the same problem.

Oh well :-(

What else can i do ????

Show us a sequence of queries that causes these messages, and we'll
fix it ...

regards, tom lane

The messages show ups in two queries

This is the first query:

select
cod_alma,direccion,nom_alma,nomc_alma,ruc,ciudad,autoriza,que_precio,
cotizacion,ban_cierre,fech_pro
from tab_alma;

This is the structure:

          Table "tab_alma"
 Attribute  |    Type     | Modifier
------------+-------------+----------
 cod_alma   | varchar(2)  |
 nom_alma   | varchar(40) |
 cta_cont   | varchar(6)  |
 clase_alma | varchar(1)  |
 nomc_alma  | varchar(10) |
 ruc        | varchar(14) |
 ciudad     | varchar(15) |
 cant_ubic  | float8      |
 cant_emis  | float8      |
 cotizacion | float8      |
 dia_libre  | varchar(1)  |
 fech_pant  | date        |
 fech_pro   | date        |
 fech_corte | date        |
 es_corte   | boolean     |
 ban_cierre | boolean     |
 corte_luz  | boolean     |
 que_precio | varchar(1)  |
 autoriza   | boolean     |
 clave_vta  | varchar(6)  |
 clave_iva  | varchar(6)  |
 direccion  | varchar(40) |
 bco_socied | varchar(6)  |
 bco_contin | varchar(6)  |
 impto_rta  | varchar(6)  |
 secuen_aud | float8      |
 tiket      | varchar(6)  |
 tiket_dev  | varchar(6)  |
 tiket_nul  | varchar(6)  |
 cup_tarjf  | varchar(2)  |
Index: itab_alma

This is the second query:

select posicion,tipo,ind_micro,ini_dia,ind_tiket
from scr_usua where login_i='" +LogIni+"';

This is the structure:

Table "scr_usua"
Attribute | Type | Modifier
------------+-------------+----------
login_i | varchar(10) |
nom_usua | varchar(30) |
estacion | varchar(12) |
tipo | varchar(1) |
tiket | varchar(6) |
zeta | varchar(4) |
ini_dia | boolean |
fech_ini | date |
hora_ini | varchar(10) |
fech_cie | date |
hora_cie | varchar(10) |
ind_x | boolean |
ind_z | boolean |
ind_estado | boolean |
ind_pago | boolean |
ind_reci | boolean |
ind_tiket | boolean |
cla_tiket | varchar(1) |
tike_nulo | varchar(6) |
tike_pdte | varchar(6) |
ind_txc | boolean |
clave | varchar(13) |
emi_anu | boolean |
emi_dev | boolean |
emi_dscto | boolean |
emi_cre | boolean |
emi_tar | boolean |
emi_ant | boolean |
emi_gto | boolean |
emi_pro | boolean |
posicion | varchar(3) |
ind_micro | boolean |
tiket_dev | varchar(6) |
tiket_rec | varchar(6) |
tiket_nul | varchar(6) |
Indices: iscr_usu1,
iscr_usua

Regards,

Karla

Karla Peralta <karlaper@elrosado.com> writes:

A bug with symptoms similar to this was fixed in 7.0.3. Please
try 7.0.3, and let us know if you still have problems.

Now I'm using postgresql-7.0.3-2 but I have the same problem.

Oh well :-(

What else can i do ????

Show us a sequence of queries that causes these messages, and we'll
fix it ...

regards, tom lane

Karla Peralta <karlaper@elrosado.com> writes:

Show us a sequence of queries that causes these messages, and we'll
fix it ...

The messages show ups in two queries

It hardly seems likely that such simple queries would trigger a failure
like this. I believe, for example, that you must be using a cursor
declaration in there somewhere, else the portal code wouldn't get
invoked.

Please provide the *complete* sequence of commands that causes this.

Also, the table declarations would be more useful if given as a schema
dump (pg_dump -s).

regards, tom lane

Tom Lane wrote:

Karla Peralta <karlaper@elrosado.com> writes:

Show us a sequence of queries that causes these messages, and we'll
fix it ...

The messages show ups in two queries

It hardly seems likely that such simple queries would trigger a failure
like this. I believe, for example, that you must be using a cursor
declaration in there somewhere, else the portal code wouldn't get
invoked.

Please provide the *complete* sequence of commands that causes this.

Also, the table declarations would be more useful if given as a schema
dump (pg_dump -s).

regards, tom lane

The problem looks like is done.
I changed to postgresql-7.0.3-2.
I changed the postmaster's options in the file postmaster.opts.default,
now I'm using -i -B 128 -N 64.
I changed the group of the users for permissions.

It's working ok, but I'm still testing.

Thanks

Karla