Re: [BUGS] code regression in 6.5.3, pl_comp.c
Yes, that is fixed in 7.0 beta. > > > POSTGRESQL BUG REPORT TEMPLATE > > > > Your name : David Hill > Your email address: [EMAIL PROTECTED] > > > System Configuration > - > Architecture (example: Intel Pentium) : Compaq Alpha > > Operating System (example: Linux 2.0.26 ELF): Compaq Tru64 UNIX v4.0 > > PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3 > > Compiler used (example: gcc 2.8.0) : Compaq cc > > > Please enter a FULL description of your problem: > > > The file ./src/pl/plpgsql/src/pl_comp.c failed to compile. Diffs > between 6.5.3 and 6.5.2 show that the keyword extern was removed from a > number of variables. I found that I had to restore one of these extern > keywords or the compiler would complain of an uncompleted reference. > As the variable plpgsql_yytext is not defined within the contect > of pl_comp.c, the compiler was correct to complain. > > > Please describe a way to repeat the problem. Please try to provide a > concise reproducible example, if at all possible: > -- > > Compile using cc on Compaq's Tru64 v4.0d or later. > > > > If you know how this problem might be fixed, list the solution below: > - > > Diff of my fix: > > The file is ./src/pl/plpgsql/src/pl_comp.c > > *** pl_comp.c Thu Sep 23 15:13:55 1999 > --- /tmp/pl_comp.cThu Mar 23 16:36:05 2000 > *** > *** 69,75 >*/ > PLPGSQL_YYSTYPE plpgsql_yylval; > int plpgsql_yylineno; > ! charplpgsql_yytext[]; > > voidplpgsql_yyerror(const char *s); > > --- 69,75 >*/ > PLPGSQL_YYSTYPE plpgsql_yylval; > int plpgsql_yylineno; > ! extern char plpgsql_yytext[]; > > voidplpgsql_yyerror(const char *s); > > > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[BUGS] initdb bug
POSTGRESQL BUG REPORT TEMPLATE Your name : Steven Smith Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Sun UltraSparc 1 Operating System (example: Linux 2.0.26 ELF) : RedHat Sparc Linux 6.1 PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3 Compiler used (example: gcc 2.8.0) : egcs-2.91.66 Please enter a FULL description of your problem: Fresh installation of Postgresql, no previous version on system. Compiled postgresql using sparc32 environment. Installed as root. Changed to postgresql user 'su - postgres' PGLIB & PGDATA set in environment postgres uid owns PGDATA directory initdb fails to run [postgres@laptop4 postgres]$ initdb We are initializing the database system with username postgres (uid=150). This user will own all the files and must also own the server process. Creating template database in /d1/postgress/base/template1 ERROR: Attribute 'aggtransfn1' is repeated ERROR: Attribute 'aggtransfn1' is repeated initdb: could not create template database initdb: cleaning up by wiping out /d1/postgress/base/template1 Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- If you know how this problem might be fixed, list the solution below: - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven G Smith Room: 317Raytheon Phone: 301-794-3026 4500 Forbes Boulevard FAX: 301-794-3165 Lanham, MD 20706
Re: [BUGS] initdb bug
Steven G Smith <[EMAIL PROTECTED]> writes: > Creating template database in /d1/postgress/base/template1 > ERROR: Attribute 'aggtransfn1' is repeated > ERROR: Attribute 'aggtransfn1' is repeated > initdb: could not create template database Hmm. That seems real familiar. I think we have seen this symptom before and it turned out to be the result of a specific kind of porting problem. Unfortunately, I forget just what, and until our Web index for the mail list archives gets fixed, I can't easily search the archives for the earlier report :-(. You could try downloading the FTP-able archives at ftp://ftp.postgresql.org/pub/majordomo/ and looking for references to 'aggtransfn' (probably in the bugs or hackers lists). But what I'd *really* suggest that you do is grab 7.0beta3 from ftp://ftp.postgresql.org/pub/ and see if that works. The problem is probably fixed (and if it isn't, we need to know!). 7.0beta is already more stable than any 6.5 release, as far as we can tell, so running a beta release shouldn't scare you too much. regards, tom lane
[BUGS] code regression in 6.5.3, pl_comp.c
POSTGRESQL BUG REPORT TEMPLATE Your name : David Hill Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Compaq Alpha Operating System (example: Linux 2.0.26 ELF) : Compaq Tru64 UNIX v4.0 PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3 Compiler used (example: gcc 2.8.0) : Compaq cc Please enter a FULL description of your problem: The file ./src/pl/plpgsql/src/pl_comp.c failed to compile. Diffs between 6.5.3 and 6.5.2 show that the keyword extern was removed from a number of variables. I found that I had to restore one of these extern keywords or the compiler would complain of an uncompleted reference. As the variable plpgsql_yytext is not defined within the contect of pl_comp.c, the compiler was correct to complain. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- Compile using cc on Compaq's Tru64 v4.0d or later. If you know how this problem might be fixed, list the solution below: - Diff of my fix: The file is ./src/pl/plpgsql/src/pl_comp.c *** pl_comp.c Thu Sep 23 15:13:55 1999 --- /tmp/pl_comp.c Thu Mar 23 16:36:05 2000 *** *** 69,75 */ PLPGSQL_YYSTYPE plpgsql_yylval; int plpgsql_yylineno; ! char plpgsql_yytext[]; void plpgsql_yyerror(const char *s); --- 69,75 */ PLPGSQL_YYSTYPE plpgsql_yylval; int plpgsql_yylineno; ! extern char plpgsql_yytext[]; void plpgsql_yyerror(const char *s);
[BUGS] Query fails after vacuum
I am running 6.5.3 on a tables with >300,000 rows. I've seen lots of cases where queries fail if I haven't done a vacuum analyze; I understand this is one of the quirks of PostgreSQl. However, below is an example of a query that fails if I HAVE done a vacuum analyze. Therefore, I have no way of getting this database into a state where all queries will perform as expected! Any ideass, atest=> SELECT COUNT(s_1.s_doc) FROM s_n_grantor AS s_1,s_n_grantee AS s_2 WHERE s_1.value LIKE 'davis j%' AND s_2.value LIKE 'east%' AND s_1.s_doc=s_2.s_doc atest-> ; count - 30 (1 row) atest=> explain SELECT COUNT(s_1.s_doc) FROM s_n_grantor AS s_1,s_n_grantee AS s _2 WHERE s_1.value LIKE 'davis j%' AND s_2.value LIKE 'east%' AND s_1.s_doc=s_2. s_doc; NOTICE: QUERY PLAN: Aggregate (cost=10.56 rows=1 width=24) -> Nested Loop (cost=10.56 rows=1 width=24) -> Index Scan using s_n_grantee_pkey on s_n_grantee s_2 (cost=8.56 row s=1 width=12) -> Index Scan using s_n_grantor_pkey on s_n_grantor s_1 (cost=2.01 row s=1 width=12) EXPLAIN atest=> vacuum analyze atest-> ; VACUUM atest=> atest=> SELECT COUNT(s_1.s_doc) FROM s_n_grantor AS s_1,s_n_grantee AS s_2 WHERE s_1.value LIKE 'davis j%' AND s_2.value LIKE 'east%' AND s_1.s_doc=s_2.s_doc; count - 0 (1 row) atest=> explain SELECT COUNT(s_1.s_doc) FROM s_n_grantor AS s_1,s_n_grantee AS s _2 WHERE s_1.value LIKE 'davis j%' AND s_2.value LIKE 'east%' AND s_1.s_doc=s_2. s_doc; NOTICE: QUERY PLAN: Aggregate (cost=4836.60 rows=1 width=24) -> Merge Join (cost=4836.60 rows=1 width=24) -> Index Scan using s_n_grantee_pkey on s_n_grantee s_2 (cost=2182.43 rows=18 width=12) -> Index Scan using s_n_grantor_pkey on s_n_grantor s_1 (cost=2651.53 rows=62 width=12)
Re: [BUGS] Query fails after vacuum
Robert Berger <[EMAIL PROTECTED]> writes: > I am running 6.5.3 on a tables with >300,000 rows. I've seen lots of > cases where queries fail if I haven't done a vacuum analyze; I > understand this is one of the quirks of PostgreSQl. You do? It's not a known failure mode to my knowledge --- the query might be slow, but it should produce a correct answer. > However, below is an example of a query that fails if I HAVE done a > vacuum analyze. That's not a known failure mode either. I don't know what's going on here, but I'm guessing you've got some fairly fundamental porting problem. What platform and compiler are you using? Do the regression tests pass for you? Another line of thought: the mergejoin you're showing as the culprit is absolutely dependent on the assumption that both indexes are sorted in the same order. Once or twice we have seen bizarre trouble reports that turned out to be due to having started the postmaster with different LOCALE settings at different times, so that the sort ordering of a text-column index got completely messed up by inserts occuring with different ideas of what the ordering should be. If you aren't careful about starting the postmaster with the same environment variables every time, this might be your problem. A recovery method if you suspect this could apply is to drop and recreate the suspect indexes. regards, tom lane
