[BUGS] RE: iofflush psql 7.0.3 coredump on RH 6.1
Sod's Law, isn't it? The minute you report a bug, you find a workaround. In this case, disabling readline starts up the client OK. (That'd be : [postgres@cartman pgsql]$ psql -n -d honeypi Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit honeypi=# ) Thanks - could probably do with fixing , though? I'll try upgrading readline on this system ,and see what happens. Cheers. > Reading symbols from /lib/libnss_files.so.2...done. > #0 0x4014a4af in _IO_fflush (fp=0x401e5f40) at iofflush.c:41 > 41 iofflush.c: No such file or directory. > (gdb) backtrace > #0 0x4014a4af in _IO_fflush (fp=0x401e5f40) at iofflush.c:41 > #1 0x4009ed97 in rl_prep_terminal () from /usr/lib/libreadline.so.4.0 > #2 0x4009996f in readline () from /usr/lib/libreadline.so.4.0 > #3 0x804e658 in gets_interactive () > -- Rasputin Jack of All Trades :: Master of Nuns
[BUGS] I'm not able to install PostgreSQL
I'm trying to install PostgreSQL 7.0.2 in Solaris 8 Intel platform, but I'm getting the following messages when I run gmake: gmake[2]: Leaving directory `/export/home/zfbf/lixo2/postgresql-7.0.2/src/backend/executor' gmake -C lib all gmake[2]: Entering directory `/export/home/zfbf/lixo2/postgresql-7.0.2/src/backend/lib' gcc -I../../include -I../../backend-Wall -Wmissing-prototypes -Wmissing-declarations -I..-c -o bit.o bit.c gcc -I../../include -I../../backend-Wall -Wmissing-prototypes -Wmissing-declarations -I..-c -o fstack.o fstack.c gcc -I../../include -I../../backend-Wall -Wmissing-prototypes -Wmissing-declarations -I..-c -o hasht.o hasht.c gcc -I../../include -I../../backend-Wall -Wmissing-prototypes -Wmissing-declarations -I..-c -o lispsort.o lispsort.c gcc -I../../include -I../../backend-Wall -Wmissing-prototypes -Wmissing-declarations -I..-c -o stringinfo.o stringinfo.c stringinfo.c: In function `appendStringInfo': stringinfo.c:104: `va_list' undeclared (first use in this function) stringinfo.c:104: (Each undeclared identifier is reported only once stringinfo.c:104: for each function it appears in.) stringinfo.c:104: parse error before `args' stringinfo.c:121: warning: implicit declaration of function `va_start' stringinfo.c:121: `args' undeclared (first use in this function) stringinfo.c:124: warning: implicit declaration of function `va_end' gmake[2]: *** [stringinfo.o] Error 1 gmake[2]: Leaving directory `/export/home/zfbf/lixo2/postgresql-7.0.2/src/backend/lib' gmake[1]: *** [lib.dir] Error 2 gmake[1]: Leaving directory `/export/home/zfbf/lixo2/postgresql-7.0.2/src/backend' gmake: *** [all] Error 2 What should I do? sincerely, Zenon Farias Braga F. _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: [BUGS] Solaris 8 / still waiting
It seems the problem is > checking for ANSI C header files... no which causes not to be included. Dunno what about Solaris is nonstandard enough to fool autoconf's test, but I see that the AC_HEADER_STDC macro tests quite a bit more than just whether the header files exist. Try modifying src/include/c.h so that and are included unconditionally. That's how it's done in current sources... regards, tom lane
Re: [BUGS] bug with postgresql
mohamed hgug <[EMAIL PROTECTED]> writes: > After a successful installation of postgresql (7.0.3), when i want to start > using it, i have a problemes: > in the directory /usr/local/pgsql/bin i type ./psql , and i have this > result: > welcome to psql, the postgresql interactive terminal. > Type \h for help > \? .. > \g .. > \q to quit > segmentation default. Hmm, does psql start up OK when you invoke it with -n ? If so, this sounds a lot like another recent report of broken libreadline support. You may need to install a newer libreadline. regards, tom lane
[BUGS] Outer joins in views
Grzegorz M. Mucha ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Outer joins in views Long Description In the 7.1 devel version, the OUTER JOIN statementes are working, but not in VIEWs. I have created the below listed view, and while it allows to be created, any attempt of using it ends with: ERROR: Internal error: no jointree entry for rel *OLD* Sample Code create view ec_recommendations_cats_view as select recs.recommendation_id, COALESCE(cats.category_name,COALESCE(subs.category_name,subsubs.category_name)) AS the_category_name, COALESCE(subs.subcategory_name,subsubs.subcategory_name) AS the_subcategory_name, subsubs.subsubcategory_name AS the_subsubcategory_name, p.product_name, c.user_class_name from ec_products p, ec_product_recommendations recs LEFT OUTER JOIN ec_categories cats on recs.category_id = cats.category_id LEFT OUTER JOIN ec_subcategories_augmented subs on recs.subcategory_id = subs.subcategory_id LEFT OUTER JOIN ec_subsubcategories_augmented subsubs on recs.subsubcategory_id = subsubs.subcategory_id left outer join ec_user_classes c on recs.user_class_id=c.user_class_id where recs.active_p='t' and recs.product_id = p.product_id; No file was uploaded with this report
[BUGS] Rules with Conditions: Still Doesn't Work (Bug Rpt)
(sorry for cross-posting a bug report directly to pgsql- hackers, but it started here, and I know it's still a topic of conversation.) About a week ago, I posted to pgsql-bugs and pgsql- hackers a VIEW that shows all user table fields w/comment, if any, as well as 2 RULES that tried to allow for updates to this view that would either (as appropriate) INSERT to pg_description, or UPDATE to pg_description. Tom Lane pointed out that, given the current handling of conditional rules, this should be one rule, with two actions. For, this either fails to work, or in some circumstances, or in some circumstances, crashes the backend. The problems are demonstrated below, with non-system tables. I show a few possible attempts at a workable solutions, but all either: - insert nothing - complain about "JOIN qualification may not refer -- to other relations" - drop connection to backend Is this an actual bug? Am I missing something still? Thanks! -- -- following is a simplified case that uses non-system -- tables -- updating existing records works, but not update- -- this becomes insert create table p (pid int not null primary key, txt text); insert into p values (1,'parent1'); insert into p values (2,'parent2'); create table c (pid int, descrip text); insert into c values (1,'descrip1'); create view v as select p.pid, txt, descrip from p left outer join c on p.pid=c.pid; create rule r as on update to v do instead ( insert into c (pid, descrip) select old.pid, new.descrip where old.descrip isnull; update c set descrip=new.descrip where c.pid=old.pid; ); update v set descrip='test' where pid=1; select * from v;-- works fine update v set descrip='test' where pid=2; select * from c;-- doesn't work? -- perhaps the problem is that the update fails on new -- records, since there was no old pid? -- try with slightly different rule (update is -- different): drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) select old.pid, new.descrip where old.descrip isnull; update c set descrip=new.descrip where c.pid=new.pid; ); update v set descrip='test' where pid=2; -- gets error "ERROR: JOIN qualification may not refer -- to other relations" -- try again w/no update action at all, just see if the -- insert action should work: drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) select old.pid, new.descrip ); update v set descrip='test' where pid=2; -- inserts w/pid=0, so old.pid obviously <> 2 (?) -- try again w/new.pid instead of old.pid drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) select new.pid, new.descrip ); update v set descrip='test' where pid=2; -- gets error "ERROR: JOIN qualification may not refer -- to other relations" -- try w/o select but w/values drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) values( new.pid, new.descrip ) ); update v set descrip='test' where pid=2; -- gets error "backend closed the channel unexpectedly." -- try w/o "new', but with current drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) values( current.pid, current.descrip ) ); update v set descrip='test' where pid=2; -- gets error "backend closed the channel unexpectedly." -- try w/different view using UNION rather than OUTER -- JOIN drop view v; create view v as select p.pid, txt, descrip from p join c on p.pid=c.pid union select p.pid, txt, null from p where not exists (select * from c where c.pid=p.pid); -- recreate rule that didn't work because of "JOIN -- qualification" drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) select new.pid, new.descrip ); update v set descrip='test' where pid=2; -- gets error "ERROR: JOIN qualification may not refer -- to other relations" -- try w/subselected view rather than UNION or OUTER JOIN create view v as select p.pid, txt, (select descrip from c where c.pid=p.pid) as descrip from p; -- recreate rule that didn't work because of "JOIN -- qualification" drop rule r; create rule r as on update to v do instead ( insert into c (pid, descrip) select new.pid, new.descrip ); update v set descrip='test' where pid=2; -- gets error "ERROR: JOIN qualification may not refer -- to other relations" -- Joel Burton, Director of Information Systems -*- [EMAIL PROTECTED] Support Center of Washington (www.scw.org)
[BUGS] initdb on Alpha dies with spinlock errors
Carl Perry ([EMAIL PROTECTED]) reports a bug with a severity of 1 The lower the number the more severe it is. Short Description initdb on Alpha dies with spinlock errors Long Description Compiled PostgreSQL 7.0.2 on my 21164 Alpha running SuSE 6.4 AXP. Compiled fine, but when trying to run initdb I recieve the following output: This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Creating database system directory /home/postgres/data Creating database system directory /home/postgres/data/base Creating database XLOG directory /home/postgres/data/pg_xlog Creating template database in /home/postgres/data/base/template1 [ED: 30 second pause here] FATAL: s_lock(202f29b0) at spin.c:116, stuck spinlock. Aborting. FATAL: s_lock(202f29b0) at spin.c:116, stuck spinlock. Aborting. initdb failed. Removing /home/postgres/data. Removing temp file /tmp/initdb.13925. Compiled using egcs-1.1.2, rest is SuSE 6.4 stock. Running on 2.4.0-test11-ac4. Any ideas? Sample Code No file was uploaded with this report
Re: [BUGS] Outer joins in views
[EMAIL PROTECTED] writes: > In the 7.1 devel version, the OUTER JOIN statementes are working, but > not in VIEWs. I have created the below listed view, and while it > allows to be created, any attempt of using it ends with: > ERROR: Internal error: no jointree entry for rel *OLD* Thanks for the report. However, I can't easily reproduce it with just the CREATE VIEW command. Could I have CREATE TABLE statements for the referenced tables, too, please? regards, tom lane
Re: [BUGS] initdb on Alpha dies with spinlock errors
[EMAIL PROTECTED] writes: > initdb on Alpha dies with spinlock errors Make sure it's compiled -O0. We're hoping to clean up the Alpha portability problems for 7.1, but 7.0.* won't work very well on Alpha without -O0 :-( regards, tom lane
Re: [BUGS] initdb on Alpha dies with spinlock errors
Tom Lane wrote: > > [EMAIL PROTECTED] writes: > > initdb on Alpha dies with spinlock errors > > Make sure it's compiled -O0. > > We're hoping to clean up the Alpha portability problems for 7.1, > but 7.0.* won't work very well on Alpha without -O0 :-( Or Ryan Kirkpatrick's patches. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [BUGS] Rules with Conditions: Still Doesn't Work (Bug Rpt)
"Joel Burton" <[EMAIL PROTECTED]> writes: > The problems are demonstrated below, with non-system tables. Wow, what a great bunch of test cases! You've exposed a number of bugs in the current sources. I'm working on fixes, but have run out of steam for today... regards, tom lane