[BUGS] RE: iofflush psql 7.0.3 coredump on RH 6.1

2000-12-04 Thread Rasputin

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

2000-12-04 Thread Zenon Braga F.

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

2000-12-04 Thread Tom Lane

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

2000-12-04 Thread Tom Lane

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

2000-12-04 Thread pgsql-bugs

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)

2000-12-04 Thread Joel Burton

(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

2000-12-04 Thread pgsql-bugs

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

2000-12-04 Thread Tom Lane

[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

2000-12-04 Thread Tom Lane

[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

2000-12-04 Thread Lamar Owen

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)

2000-12-04 Thread Tom Lane

"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