Thread: PortalHeapMemoryFree...in diskless client
Your name: Karla Peralta Your email address: karlaper@elrosado.com System Configuration: Architecture : Pentium II Operating System : RedHat 6.2 PostgreSQL version : 7.0.2-2 Compiler used : FlagShip-4.48-7451 I'm using diskless, my server has 64mb of memory. I have instaled: FlagShip-4.48-7451 FS2tools-4.48-7451 SQLkit_PG 1.00 My client has 16Mb of memory and it's a pentium. Please enter a FULL descripcion of your problem: 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 ! Notice: PortalHeapMemoryFree: 0x0x822b1c0 not in alloc set ! Notice: PortalHeapMemoryFree: 0x0x822b550 not in alloc set ! Notice: PortalHeapMemoryFree: 0x0x822b2b8 not in alloc set ! Notice: PortalHeapMemoryFree: 0x0x822a220 not in alloc set ! Notice: PortalHeapMemoryFree: 0x0x822b1b8 not in alloc set ! Notice: buffer leak: [060] (freeNext=-3, freePrev=-3, relname=tab_alma blockNum=0, flags=0x4, refcount=1 1) At this point I'm just doing a simple select from tab_alma. Later the program do a select from another table scr_usua and I get it again. I don't know what is the problem because sometimes it works fine. Regards Karla Peralta
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 ????
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
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:
>> 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