[BUGS] installation problem
I am finding it difficult to install postgresql7.3.2 on linux advanced server. Repeatedly its asking for some or other files. Please let me know the exact procedure and what are the dependency files required for the same. bye guruprasad ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] installation problem
On Monday 08 December 2003 06:56, Sh A Guru Prasad wrote: > I am finding it difficult to install postgresql7.3.2 on > linux advanced server. Repeatedly its asking for some or > other files. Please let me know the exact procedure and > what are the dependency files required for the same. This problem is not really for the bugs mailing list. Please subscribe to the general mailing list and try again there. Some points: 1. You don't want to install 7.3.2 - try 7.3.5 or 7.4.1 2. You don't say whether you are using RPM/deb or source installation 3. You don't say what distribution of Linux you are using. 4. You don't give any error message details 5. You don't say what point in the installation guide you have reached. If you can address these points, ask again on the general list and we'll soon have you up and running. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
pgsql-bugs@postgresql.org
On Mon, 24 Nov 2003, Antony Brooke-Wood wrote: > HI, > > We are getting the following error through a JSP. > > We received the same error for both 7.3.1 through 7.3.4 and several JDBC > driver changes (currently running the latest). > > java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(String.java:444) > at > org.postgresql.jdbc1.AbstractJdbc1ResultSet.toBoolean(AbstractJdbc1Resul > tSet.java:684) > at > org.postgresql.jdbc1.AbstractJdbc1ResultSet.getBoolean(AbstractJdbc1Resu > ltSet.java:102) > at This problem was fixed nearly three months ago in a patch from Kim Ho, but unfortunately the builds on jdbc.postgresql.org have not been updated in some time. This fix is in the 7.4 and HEAD cvs branches, but a source build is the only way to get it at this point. Kris Jurka ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] 7.4 build error in Solaris
Hi everyone, I encountered the following build error when building PostgreSQL 7.4 in Solaris 9 using SUN workshop. Any idea what to do here ? Gan "pl_funcs.c", line 403: warning: argument #1 is incompatible with prototype: prototype: pointer to const unsigned char : "../../../../src/include/mb/ pg_wchar.h", line 291 argument : pointer to char UX tsort: INFORM: cycle in data pl_comp.o pl_gram.o "plperl.c", line 317: undefined symbol: thr "plperl.c", line 317: left operand of "->" must be pointer to struct/union "plperl.c", line 323: left operand of "->" must be pointer to struct/union "plperl.c", line 323: left operand of "->" must be pointer to struct/union "plperl.c", line 323: left operand of "->" must be pointer to struct/union "plperl.c", line 323: left operand of "->" must be pointer to struct/union "plperl.c", line 437: undefined symbol: thr "plperl.c", line 437: left operand of "->" must be pointer to struct/union "plperl.c", line 443: left operand of "->" must be pointer to struct/union "plperl.c", line 443: left operand of "->" must be pointer to struct/union "plperl.c", line 443: left operand of "->" must be pointer to struct/union "plperl.c", line 443: left operand of "->" must be pointer to struct/union cc: acomp failed for plperl.c make[3]: *** [plperl.o] Error 2 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 -- ++ | Seum-Lim GAN email : [EMAIL PROTECTED] | | Lucent Technologies| | 2000 N. Naperville Road, 6B-403F tel : (630)-713-6665 | | Naperville, IL 60566, USA.fax : (630)-713-7272 | | web : http://inuweb.ih.lucent.com/~slgan | ++ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] 7.4 build error in Solaris
Seum-Lim Gan <[EMAIL PROTECTED]> writes: > I encountered the following build error when building PostgreSQL 7.4 > in Solaris 9 using SUN workshop. Any idea what to do here ? Is CVS tip any better? I think this fix might be relevant: 2003-11-24 08:11 petere * configure, configure.in, src/include/pg_config.h.in, src/interfaces/ecpg/ecpglib/connect.c, src/interfaces/ecpg/ecpglib/misc.c, src/port/thread.c, src/tools/thread/thread_test.c (REL7_4_STABLE): Rename USE_THREADS to ENABLE_THREAD_SAFETY to avoid name clash with Perl. Fixes compliation failure with --enable-thread-safety --with-perl and Perl 5.6.1. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] 7.4 build error in Solaris
Hi Tom, Yes this is helpful. I will do the change and recompile and let you know the result. Thanks. Gan At 12:09 pm -0500 2003/12/8, Tom Lane wrote: Seum-Lim Gan <[EMAIL PROTECTED]> writes: I encountered the following build error when building PostgreSQL 7.4 in Solaris 9 using SUN workshop. Any idea what to do here ? Is CVS tip any better? I think this fix might be relevant: 2003-11-24 08:11 petere * configure, configure.in, src/include/pg_config.h.in, src/interfaces/ecpg/ecpglib/connect.c, src/interfaces/ecpg/ecpglib/misc.c, src/port/thread.c, src/tools/thread/thread_test.c (REL7_4_STABLE): Rename USE_THREADS to ENABLE_THREAD_SAFETY to avoid name clash with Perl. Fixes compliation failure with --enable-thread-safety --with-perl and Perl 5.6.1. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- ++ | Seum-Lim GAN email : [EMAIL PROTECTED] | | Lucent Technologies| | 2000 N. Naperville Road, 6B-403F tel : (630)-713-6665 | | Naperville, IL 60566, USA.fax : (630)-713-7272 | | web : http://inuweb.ih.lucent.com/~slgan | ++ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] BUG #1002: Update using rule on view with inheritance alters 0 rows, 1 row expected.
The following bug has been logged online: Bug reference: 1002 Logged by: Chris Piker Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: RedHat Linux 9 Description:Update using rule on view with inheritance alters 0 rows, 1 row expected. Details: Specific Version Using postgres binary distribution that includes the file: postgresql-7.4-0.3PGDG.i386.rpm Schema (with data) -- -- Groups and Permissions tables create table groups( gid int4 primary key, short_name varchar(32) ); create table perms( gid integer not null references groups(gid) on update cascade on delete cascade, usename name not null, primary key (gid, usename), sel boolean not null, ins boolean not null, up boolean not null, del boolean not null ); -- Data Object Tables... create table base( id integer primary key, gid integer references groups(gid) on update cascade on delete set null, obj_name varchar(128) not null ); create table child_1( primary key(id), foreign key(gid) references groups(gid) on update cascade on delete set null, child1_stuff text ) inherits (base); create table child_2( primary key(id), foreign key(gid) references groups(gid) on update cascade on delete set null, child2_stuff text ) inherits (child_1); -- Data for permission tables: insert into groups values (1,'users'); insert into perms values (1,'postgres',true,true,true,true); -- Data for object tables: insert into base values (1,1,'Base Object'); insert into child_1 values (2,1,'Child 1 Object','Stuff'); insert into child_2 values (3,1,'Child 2 Object','Stuff','Stuff'); -- Update view on table "base" create view base_up as select base.* from perms,base where perms.gid = base.gid and perms.usename = session_user and perms.up = true; create rule R_base_up as on update to base_up do instead update base set gid = new.gid, obj_name = new.obj_name where old.id = id; grant select,update on base_up to public; Problem Query - The following query updates 0 rows, when 1 row is expected to be updated: update base_up set obj_name = 'new name' where id = 3; The following related query updates 1 row, when 1 row is expected: update base_up set obj_name = 'new name' where id = 2; Explain clearly shows which parts of the query plan are in error. I can send the explain analyze output if needed. Thanks for your time on this issue. -- [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1002: Update using rule on view with inheritance alters 0 rows, 1 row expected.
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> The following query updates 0 rows, when 1 row is
> expected to be updated:
Nice catch. The attached patch seems to fix it.
regards, tom lane
*** src/backend/optimizer/util/clauses.c.orig Sat Nov 29 14:51:51 2003
--- src/backend/optimizer/util/clauses.cMon Dec 8 20:41:07 2003
***
*** 2960,2995
RangeTblEntry *rte = (RangeTblEntry *) lfirst(rt);
RangeTblEntry *newrte;
switch (rte->rtekind)
{
case RTE_RELATION:
case RTE_SPECIAL:
! /* nothing to do, don't bother to make a copy */
break;
case RTE_SUBQUERY:
if (!(flags & QTW_IGNORE_RT_SUBQUERIES))
{
- FLATCOPY(newrte, rte, RangeTblEntry);
CHECKFLATCOPY(newrte->subquery, rte->subquery,
Query);
MUTATE(newrte->subquery, newrte->subquery,
Query *);
- rte = newrte;
}
break;
case RTE_JOIN:
if (!(flags & QTW_IGNORE_JOINALIASES))
{
- FLATCOPY(newrte, rte, RangeTblEntry);
MUTATE(newrte->joinaliasvars,
rte->joinaliasvars, List *);
- rte = newrte;
}
break;
case RTE_FUNCTION:
- FLATCOPY(newrte, rte, RangeTblEntry);
MUTATE(newrte->funcexpr, rte->funcexpr, Node *);
- rte = newrte;
break;
}
! FastAppend(&newrt, rte);
}
query->rtable = FastListValue(&newrt);
return query;
--- 2960,2990
RangeTblEntry *rte = (RangeTblEntry *) lfirst(rt);
RangeTblEntry *newrte;
+ FLATCOPY(newrte, rte, RangeTblEntry);
switch (rte->rtekind)
{
case RTE_RELATION:
case RTE_SPECIAL:
! /* we don't bother to copy eref, aliases, etc; OK? */
break;
case RTE_SUBQUERY:
if (!(flags & QTW_IGNORE_RT_SUBQUERIES))
{
CHECKFLATCOPY(newrte->subquery, rte->subquery,
Query);
MUTATE(newrte->subquery, newrte->subquery,
Query *);
}
break;
case RTE_JOIN:
if (!(flags & QTW_IGNORE_JOINALIASES))
{
MUTATE(newrte->joinaliasvars,
rte->joinaliasvars, List *);
}
break;
case RTE_FUNCTION:
MUTATE(newrte->funcexpr, rte->funcexpr, Node *);
break;
}
! FastAppend(&newrt, newrte);
}
query->rtable = FastListValue(&newrt);
return query;
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [BUGS] Bug in pg_restore or in postmaster itself?
Joseph Tate <[EMAIL PROTECTED]> writes: > pg_restore: connecting to database for restore > pg_restore: dropping RULE au_d_assigned_template > pg_restore: dropping RULE au_u_assigned_template > ... More rules, triggers, constraints, indexes and functions removed > pg_restore: dropping ACL au_assigned_template > pg_restore: dropping TABLE au_assigned_template > pg_restore: NOTICE: rule au_d_assigned_template on table > assigned_template depends on table au_assigned_template > pg_restore: NOTICE: rule au_u_assigned_template on table > assigned_template depends on table au_assigned_template > pg_restore: [archiver (db)] could not execute query: ERROR: Cannot drop > table au_assigned_template because other objects depend on it > Use DROP ... CASCADE to drop the dependent objects too > pg_restore: *** aborted because of error > I find it odd that it refuses to drop table au_assigned_template because > the two rules depend on it when the rules have already been dropped. Are you sure those aren't rules on some other table that chance to have the same names as the problematic rules? Until very recently (CVS tip of a couple days ago) pg_dump did not really have the smarts to ensure that it always did things in a "safe" order that wouldn't fall foul of inter-object dependencies. I suspect what you have here is just an example of that. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Wierd MD5-authentication crash on Solaris 8
Josh Berkus <[EMAIL PROTECTED]> writes: > Solaris 8 > Summary: attempting to connect via MD5 authentication as a user > who has no password triggers a core dump of Postmaster. Is this the bsearch-of-no-elements problem recently discussed? (If you have other users who do have passwords, then it's not...) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Error compiling PostgreSQL 7.4 for Fedora Core 1
Jonathan Gardner <[EMAIL PROTECTED]> writes: > On Sunday 07 December 2003 12:48 am, Tom Lane wrote: >> Hmmm ... this is evidently a variant of ye olde "Gen_fmgrtab.sh script >> failed" problem, > So far, this is what I have. I'm attaching fmgroids.h and fmgrtab.c ( I kno= > w=20 > these are fairly sizable...) That's really bizarre. For awhile I thought you might have fmgroids.h and fmgrtab.c generated from some pre-7.4-release version of pg_proc.h, but that theory doesn't seem to hold water --- for instance your files include box_send() but not box_recv(), which were added in the same commit. I don't see a pattern to the functions you are missing. Anyone have a theory? In the absence of any brilliant insight, I'd suggest slogging through Gen_fmgrtab.sh to try to narrow down where functions are getting lost --- add code to save the various intermediate files, and see what's in 'em. If we knew exactly which step was losing the functions it'd be a leg up. > Unfortunately, I am not familiar with the internals of awk and sed. If I=20 > were hired to fix this for my platform (Fedora Core 1), I would probably=20 > rewrite Gen_fmgrtab.sh in perl. I can't see that as a plausible answer. With all due respect to Perl, it's neither more portable nor more bug-free than awk/sed. > The only other option I see is to distribute the pre-generated fmgroids.h > and fmgrtab.c with the distribution. We could fall back in that direction if we had to. But I'd like to understand why we have to, first. Gen_fmgrtab.sh has worked on all our supported platforms for a long time, and I'm disinclined to assume that it's suddenly broken ... especially on what's presumably a modern platform. I'm having a real problem with the idea that Fedora incorporates a broken awk or sed. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
