Обсуждение: ECPG failed and Postmaster getting bigger in using perl Pg
Hi everyone,
I am revamping a computer system by Red Hat 6.0 +
PostgreSQL 6.5.3 + ecpg 2.7 + C. The user interface is
perl Pg + Apache. Everything seems fine, but when I
use "top" to display long term CPU processes, I find
the postmaster is getting bigger in step of 4 kb and
performance is getting worse GRADUALLY (It seems that
perl + Pg would make the size expansion more quickly
than ECPG). Here are some data display in "top":
PID SIZE RSS SHARE TIME COMMAND
2526 1260 1260 1040 0:00 postmaster --
when postmaster started
2526 28384 20M 388 4:41 postmaster --
2 days later
I didn't find any error in tracing my program, and
the child postmaster is terminated correctly. I really
can't figure out the reason. Please give me advise.
I have installed the latest version 7.0RC5, but I
find my C program fails in ECPG 2.7 although it works
fine in PostgreSQL 6.5.3, Postmaster is getting bigger
too (perl + Pg), Here is a simple example:
1. I create a table foo_1 and insert 2 rows of data: CREATE TABLE foo_1 ( recno int PRIMARY KEY, --
PRIMARYKEY a1 int, b1 float, spare int ); insert into foo_1
values(1,10,11.1,0); insert into foo_1 values(2,20,22.2,0);
2. I write a program (Test.pgc) to get a whole row
into a structure temp by "select *":
/*
exec sql whenever sqlerror sqlprint;
*/
exec sql include sqlca;
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
main()
{ exec sql begin declare section; struct data { int recno; int a1;
float b1; int spare;
} temp; int PK_INDEX; exec sql end declare section;
exec sql connect to by2db; if (sqlca.sqlcode != 0) { printf ("connect database error =
%s\n",sqlca.sqlerrm.sqlerrmc); exit (-1); }
PK_INDEX = 1; exec sql select * into :temp from foo_1 where recno
= :PK_INDEX; if (sqlca.sqlcode != 0) { printf ("sql_select--foo_1 :
%s\n",sqlca.sqlerrm.sqlerrmc); exit (-1); } printf (" a1 = %d b1 = %f\n",temp.a1,temp.b1);
exec sql disconnect all; exit(0);
}
After executing program(Test), I got different result
in each version of PostgreSQL,
such as:
In PostgreSQL 6.5.3 + ecpg 2.7 : a1 = 10 b1 =
11.100000
In PostgreSQL 7.0RC5 + ecpg 2.7 : sql_select--foo_1
: Too few arguments in line 33.
I would REALLY appreciate some suggestions.
Thanks S.F.Lee
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
"S.F. Lee" <sflee_tw@yahoo.com> wrote:
> After executing program(Test), I got different result
> in each version of PostgreSQL,
> such as:
>
> In PostgreSQL 6.5.3 + ecpg 2.7 : a1 = 10 b1 =
> 11.100000
>
> In PostgreSQL 7.0RC5 + ecpg 2.7 : sql_select--foo_1
> : Too few arguments in line 33.
This is a bug of pre-processor in PostgreSQL-7.0RC5.
The solutions of the bug:
1. Don't use a struct host variable.
old) exec sql select * into :temp ... new) exec sql select a1,b1 into :temp.a1, :temp.b1 ...
2. Apply the next patch.
*** postgresql-7.0RC5/src/interfaces/ecpg/preproc/type.c.orig Wed May 10 14:45:55 2000
--- postgresql-7.0RC5/src/interfaces/ecpg/preproc/type.c Wed May 10 14:46:43 2000
***************
*** 198,203 ****
--- 198,209 ---- void ECPGdump_a_type(FILE *o, const char *name, struct ECPGtype * typ, const char *ind_name, struct
ECPGtype* ind_typ, const char *prefix, const char *ind_prefix) {
+ if (ind_typ == NULL)
+ {
+ ind_typ = &ecpg_no_indicator;
+ ind_name = "no_indicator";
+ }
+ switch (typ->typ) { case ECPGt_array:
--
Regards,
SAKAIDA Masaaki -- Osaka, Japan
On Wed, May 10, 2000 at 03:13:56PM +0900, SAKAIDA Masaaki wrote:
> This is a bug of pre-processor in PostgreSQL-7.0RC5.
ARGH!
> The solutions of the bug:
>
> 1. Don't use a struct host variable.
Not really a solution.
> 2. Apply the next patch.
>
> *** postgresql-7.0RC5/src/interfaces/ecpg/preproc/type.c.orig Wed May 10 14:45:55 2000
> --- postgresql-7.0RC5/src/interfaces/ecpg/preproc/type.c Wed May 10 14:46:43 2000
> ***************
> *** 198,203 ****
> --- 198,209 ----
> void
> ECPGdump_a_type(FILE *o, const char *name, struct ECPGtype * typ, const char *ind_name, struct ECPGtype * ind_typ,
constchar *prefix, const char *ind_prefix)
> {
> + if (ind_typ == NULL)
> + {
> + ind_typ = &ecpg_no_indicator;
> + ind_name = "no_indicator";
> + }
> +
This has been in before. I have no idea where it got lost. To make matters
worse this has not made it into the archive before 7.0 was released right?
Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> wrote:
> > This is a bug of pre-processor in PostgreSQL-7.0RC5.
>
> ARGH!
>
> > The solutions of the bug:
> >
> > 1. Don't use a struct host variable.
>
> Not really a solution.
This solution would be effective only when ecpg is not fixed ;-).
> > 2. Apply the next patch.
> >
> > *** postgresql-7.0RC5/src/interfaces/ecpg/preproc/type.c.orig Wed May 10 14:45:55 2000
> > --- postgresql-7.0RC5/src/interfaces/ecpg/preproc/type.c Wed May 10 14:46:43 2000
> > ***************
> > *** 198,203 ****
> > --- 198,209 ----
> > void
> > ECPGdump_a_type(FILE *o, const char *name, struct ECPGtype * typ, const char *ind_name, struct ECPGtype *
ind_typ,const char *prefix, const char *ind_prefix)
> > {
> > + if (ind_typ == NULL)
> > + {
> > + ind_typ = &ecpg_no_indicator;
> > + ind_name = "no_indicator";
> > + }
> > +
>
> This has been in before. I have no idea where it got lost.
Probably, when you were editting it, you have made a mistake,
I think :-).
BTW If ecpg is fixed, we can use a struct indicator, too. (ex.
select * into :temp :ind_temp from foo_1 ..) It is wonderful that
such a struct host variable can be used. Ecpg is very good tool.
--
Regards,
SAKAIDA Masaaki -- Osaka, Japan
Michael Meskes <meskes@postgresql.org> writes:
> ARGH!
> This has been in before. I have no idea where it got lost. To make matters
> worse this has not made it into the archive before 7.0 was released right?
Nope, not if it wasn't in CVS on Monday evening :-(. Oh well, there's
most certainly going to be a 7.0.1 ...
regards, tom lane
On Wed, May 10, 2000 at 07:53:28PM +0900, SAKAIDA Masaaki wrote: > This solution would be effective only when ecpg is not fixed ;-). It will be. > Probably, when you were editting it, you have made a mistake, > I think :-). Yup. But then I still don't know how I managed to do that. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
On Wed, May 10, 2000 at 09:52:48AM -0400, Tom Lane wrote: > Nope, not if it wasn't in CVS on Monday evening :-(. Oh well, there's > most certainly going to be a 7.0.1 ... Hopefully pretty soon. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!