Port Bug Report: configure stopped because it can't create executables

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Andreas Rippel
Your email address : [email protected]

Category : install: compile
Severity : critical

Summary: configure stopped because it can't create executables

System Configuration
- --------------------
Operating System : HP-UX 10.20

PostgreSQL version : 6.0

Compiler used : 6.4-BETA1

Hardware:
- ---------


Versions of other tools:
- ------------------------
GNU Make version 3.77
flex version 2.5.4
gcc version 2.8.1

- --------------------------------------------------------------------------

Problem Description:
- --------------------
configure ended up by saying that it can't create executables

- --------------------------------------------------------------------------

Test Case:
- ----------
being root or or normal user:
./configure --prefix=/tmp

- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Fri, 2 Oct 1998 05:18:33 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: limited subquery length of CREATE VIEW command

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Gyorgy Lendvary
Your email address : [email protected]

Category : unknown
Severity : serious

Summary: limited subquery length of CREATE VIEW command

System Configuration
- --------------------
Operating System : Linux

PostgreSQL version : 6.3.2

Compiler used :

Hardware:
- ---------
Pentium 200MMX, 64M RAM

Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
if I want to create a view from a table has many columns,
and the select query is too long, postgres gives an error message.
For instance:
there is the table example, that has 10000 columns:
column1, column2, ..., column9999, column10000

I want to create a view from the first 9998 columns:
PQexec(conn, "create view v_e as select column1, column2, ..., column9998
from example");
Postgres says, that this query is too long

- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Fri, 2 Oct 1998 12:27:06 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Core Dumped

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Ernesto Hinojosa
Your email address : [email protected]

Category : unknown
Severity : non-critical

Summary: Core Dumped

System Configuration
- --------------------
Operating System : FreeBSD 2.2.6

PostgreSQL version : 5.0

Compiler used :

Hardware:
- ---------
Pentium 166 , 80M ram

Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
After running a query in a table of 100 fields and 17026 records, It gives me one of the following errors:
malloc: Cannot allocate memory
or
Core Dumped

- --------------------------------------------------------------------------

Test Case:
- ----------
Select * from cadeg where pfp > '19980500' and pfp < '19980900';

- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Thu, 8 Oct 1998 11:29:23 -0500
From: "Jackson, DeJuan" <[email protected]>
Subject: RE: [HACKERS] Re: [COMMITTERS] 'pgsql/doc/src/sgml protocol.sgml'
So, has anyone tried the tutorials (with/with out success)? Let me know
what did and didn't work for you. We're trying to re-vamp the docs
while we have the chance, so vent. But, remember be constructive.

-DEJ

P.S. Sorry to those of you who receive many copies of this. I'll get
about 6 myself.

From scrappy
Date: Thu, 8 Oct 1998 12:47:50 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report:

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name :
Your email address :

Category : unknown
Severity : non-critical

Summary:

System Configuration
- --------------------
Operating System :

PostgreSQL version : 6.0

Compiler used :

Hardware:
- ---------


Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Fri, 9 Oct 1998 19:50:52 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Compilation suddenly stops at function bootstrap.c

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Camilo Villarreal
Your email address : [email protected]

Category : install: compile
Severity : critical

Summary: Compilation suddenly stops at function bootstrap.c

System Configuration
- --------------------
Operating System : Solaris 2.5.1

PostgreSQL version : 6.3.2

Compiler used : gcc 2.8.1

Hardware:
- ---------
Although I'm not using Linux, I wanna say I'm using a Sparc 20 station with Solaris 2.5.1.
My uname -a is: SunOS catarsis 5.5.1 Generic_103640-12 sun4m sparc sun4m

Versions of other tools:
- ------------------------
gmake (version 3.74)
bison (version 1.24)
flex (version 2.5.4)

- --------------------------------------------------------------------------

Problem Description:
- --------------------
When gcc tries to compile function bootstrap.c it can't find the file where some constants are supposed to be defined. Those constants are named like F_BOOLIN, F_BOOLOUT,F_BYTEAIN ...and so on.

- --------------------------------------------------------------------------

Test Case:
- ----------
I've tried almost all of the templates included in the distribution but none have worked. The only thing I've been doing is just typing ./configure --with-template=sparc_solaris-gcc, and then I type gmake all, and that's all. I wrote above the tools I've been using with the respective version.

- --------------------------------------------------------------------------

Solution:
- ---------
I don't have a clue !!

- --------------------------------------------------------------------------

From scrappy
Date: Mon, 12 Oct 1998 02:13:00 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: slash commands \d(or \dt,\ds etc) donot work.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Wei Zhang
Your email address : [email protected]

Category : unknown
Severity : critical

Summary: slash commands \d(or \dt,\ds etc) donot work.

System Configuration
- --------------------
Operating System : SunOS 5.5.1

PostgreSQL version : 6.3

Compiler used :

Hardware:
- ---------


Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
Using command \d, it shows message "Couldn't find any tables,
sequences or indices!". Actually, there are tables for the
database. When command \d test1 is used, the table
test1 is listed. See below.

pgsql=> \d
Couldn't find any tables, sequences or indices!
pgsql=> \d test1

Table = test1
+----------------------------------+----------------------------------+-------+
+----------------------------------+----------------------------------+-------+

- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Mon, 12 Oct 1998 08:36:07 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: backend dies due to a query

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Ari Jolma
Your email address : [email protected]

Category : runtime: back-end: SQL
Severity : non-critical

Summary: backend dies due to a query

System Configuration
- --------------------
Operating System : Linux 2.0.34 ELF

PostgreSQL version : 6.3.2

Compiler used :

Hardware:
- ---------
RedHat 5.1
Linux ahti.hut.fi 2.0.34 #2 Wed Jul 22 09:29:31 EEST 1998 i586 unknown

Versions of other tools:
- ------------------------
this is from rpm:

Name : postgresql Distribution: (none)
Version : 6.3.2 Vendor: (none)
Release : 6 Build Date: Sat Aug 8 20:23:11 1998
Install date: Tue Sep 8 09:19:16 1998 Build Host: apollo.online.no
Group : Applications/Databases Source RPM: postgresql-6.3.2-6.src.rpm
Size : 4413502
Packager : Arne Coucheron <[email protected]>


- --------------------------------------------------------------------------

Problem Description:
- --------------------
a certain kind of expression in select causes the backend to die

- --------------------------------------------------------------------------

Test Case:
- ----------
bubi=> create table a (s text);
CREATE
bubi=> insert into a (s) values ('a');
INSERT 2965801 1
bubi=> insert into a (s) values ('b');
INSERT 2965802 1
bubi=> select (s = '' or s isnull) from a;
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.


- --------------------------------------------------------------------------

Solution:
- ---------
a problem with the parser?

- --------------------------------------------------------------------------

From scrappy
Date: Mon, 12 Oct 1998 13:59:24 -0400
From: Peter Gucwa <[email protected]>
Subject: compilation problem on AIX

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Peter Gucwa
Your email address : [email protected]


System Configuration
- ---------------------
Architecture (example: Intel Pentium) :IBM RS6000

Operating System (example: Linux 2.0.26 ELF) : AIX 4.2

PostgreSQL version (example: PostgreSQL-6.3.2) : PostgreSQL-6.3.2

Compiler used (example: gcc 2.7.2) : xlc


Please enter a FULL description of your problem:
- ------------------------------------------------
The addrlen and len should be defined as size_t not int.

xlc -I../../include -I../../backend -qchars=signed -qmaxmem=8192 -qhalt=w -qsrcmsg -qcheck=divzero -I.. -c pqcomm.c -o pqcomm.o
673 | &addrlen)) < 0)
.........................................................a..............
a - 1506-280 (E) Function argument assignment between types "unsigned long*" and "int*" is not allowed.
682 | &addrlen) < 0)
........................................a.............
a - 1506-280 (E) Function argument assignment between types "unsigned long*" and "int*" is not allowed.
787 | if (ngetsockname(port->sock, &port->laddr.sa, &len) < 0)
......................................................a.........
a - 1506-280 (E) Function argument assignment between types "unsigned long*" and "int*" is not allowed.


Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------
compile on AIX



If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------
I'm not sure what is the prefered way of fixing this kind of problems.
One way to do this is to add to configure.in checking for the type of
the last argument of accept function.

From scrappy
Date: Mon, 12 Oct 1998 15:27:54 -0400 (EDT)
From: [email protected]
Subject: JOBOP Software Development Consultant

Since you listed your address on a RDBMS web site, I thought
you might be willing to help.

I represent a leading edge technology firm an seek people
To join the professional services division. The most immediate
need is for qualified people in the Atlanta, GA area, although we
need people along the entire East Coast.

The following is the job description:

Senior/Principle Consultant

Due to tremendous growth in our Sales and Professional Services
Businesses, we have the need to add a key technical resource to our
Professional Services business unit. This individual is the "go to" technical
person for the Professional Services team. We need experience
developing with C++ in both UNIX and NT environments, experience
in design and in all phases of the software development cycle,
RDBMS experience with Oracle, Sybase and NT SQL Server and the
ability to provide both pre and post sales support as needed.

The position includes: Very competitive compensation package (up to
low six figures plus bonus) Excellent benefits A chance to join a very
profitable, leading edge, fast growing organization.

If you know anyone who might be interested please forward this to them
or contact me today.

Dave Eide
Quest_IT a division of Diedre Moire Corporation
510 Horizon Center
Robbbinsville, NJ 08691
Phone: 609-584-9000 ext 273
Fax: 609-584-9575
Email: [email protected]

From scrappy
Date: Mon, 12 Oct 1998 18:27:27 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: type conversion in data types

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Ranadheer
Your email address : Reddy

Category : unknown
Severity : serious

Summary: type conversion in data types

System Configuration
- --------------------
Operating System : Linux

PostgreSQL version : 6.3.2

Compiler used :

Hardware:
- ---------
Pentium, 64M RAM

Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
Iam working on a web application using perl and postgres as
database. I want to use 'date_part' function to get month or
dow of particular date. How do I pass a string like '7/27/98' as a date to 'date_part'.

- --------------------------------------------------------------------------

Test Case:
- ----------
$Date="7/7/98";
$Mon=$DBhandle->execute("select date_part('month',$Date)");
$Fmon=$Mon->fetchrow();
print $Fmon;

# The above will not work. How do I do that




- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Mon, 12 Oct 1998 18:28:07 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: type conversion in data types

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Ranadheer Reddy
Your email address : [email protected]

Category : unknown
Severity : serious

Summary: type conversion in data types

System Configuration
- --------------------
Operating System : Linux

PostgreSQL version : 6.3.2

Compiler used :

Hardware:
- ---------
Pentium, 64M RAM

Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
Iam working on a web application using perl and postgres as
database. I want to use 'date_part' function to get month or
dow of particular date. How do I pass a string like '7/27/98' as a date to 'date_part'.

- --------------------------------------------------------------------------

Test Case:
- ----------
$Date="7/7/98";
$Mon=$DBhandle->execute("select date_part('month',$Date)");
$Fmon=$Mon->fetchrow();
print $Fmon;

# The above will not work. How do I do that




- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Mon, 12 Oct 1998 23:06:25 -0600
From: "Rick Darnell" <[email protected]>
Subject: Successful Install

I just installed Postgresql 6.3.2 successfully on my system so I could work
with Applixware Data.

The system is an i486 (16MB) running Linux 2.0.35 (Slackware 3.3). I
compiled according the instructions in the administrator's guide, and the
kinks were minor (I can't even remember specifically what they were). To
start postgresql automatically I added
su postgres -c "/usr/local/pgsql/bin/postmaster -S -D /usr/local/pgsql/data"
to /etc/rc.d/rc.local with no apparent bad karma.

The regression test failed on float8, geometry, and horology.

Thanks for a fine piece of software. For as involved as the installation
process was, it really went quite smoothly.

- --Rick Darnell
"A screw is just a nail with threads."

From scrappy
Date: Tue, 13 Oct 1998 20:49:03 +0900 (KST)
From: [email protected]
Subject: [Problem report]

begin 600 postgresbug
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0H@(" @(" @(" @(" @
M(" @(" @(" @("!03U-41U)%4U%,($)51R!215!/[email protected]$5-4$Q!5$4*/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0H*"EEO=7(@;F%M92 @(" @
M(" @(" @(" @(#H@2F%[email protected]&%R:PI9;W5R(&5M86EL(&%D9')E<W,@
M(" @(" Z(&IH($-O;F9I
M9W5R871I;VX*+2TM+2TM+2TM+2TM+2TM+2TM+2TM"B @07)C:&ET96-T=7)E
M("AE>&%M<&QE.B!);G1E;"!096YT:75M*2 @(" @(" @(#[email protected]@4&5N
M=&EU;2!-35@@,38V"@H@($]P97)A=&EN9R!3>7-T96T@*&5X86UP;&4Z($QI
M;G5X(#(N,"XR-B!%3$8I(" Z(%5N:7AW87)E(#(N,2XS(&%P<&QI8V%T:6]N
M"@D)"0D)"0D)"0D)"2 @<V5R=F5R"@H@(%!O<W1G<F5344P@=F5R<VEO;B H
M97AA;[email protected]&]S=&=R95-13"TV+C,N,BD@(#H@("!0;W-T9W)E4U%,+38N
M,RXR"@H@($-O;7!I;&5R('5S960@*&5X86UP;&4Z("!G8V,@,BXW+C(I(" @
M(" @(" @(" Z(&-C"@H*4&QE87-E(&5N=&5R(&$@1E5,3"!D97-C<FEP=&EO
M;B!O9B!Y;W5R('!R;V)L96TZ"BTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0IC;VUP;&EL92!E;G9I<F]N;65N=" Z
M"@EM86ME(#[email protected](&UA:V4*"6QE>" Z($=.52!F;&5X"@EY86-C(#H@>6%C
M8R H4WES=&5M('!R;W9I9&5D+BXI"@D);W!T:6]N("UD"@EC;VUP;&EE<B Z
M(&-C("A3>7-T96T@<')O=FED960N+BD*"@E0<F]B;&5M<R!F;VQL;W=I;F<N
M+BXN+BX[email protected]*9VUA:V4@+4,@:6YT97)F86-E<R!A;&P*9VUA:V5;,5TZ($5N
M=&5R:6YG(&1I<F5C=&]R>2!@+VAO;64O<&=S<6PO<&]S=&=R97-Q;"TV+C,N
M,B]S<F,O:6YT97)F86-E<R<*9VUA:V4@+4,@;&EB<'$@86QL"F=M86ME6S)=
M.B!%;G1E<FEN9R!D:7)E8W1O<[email protected]"]H;VUE+W!G<W%L+W!O<W1G<F5S<6PM
M-BXS+C(O<W)C+VEN=&5R9F%C97,O;&EB<'$G"FQD("U'("UZ('1E>'0@+6\@
M;&EB(&9E+65X96,N;R!F
M92UM:7-C+F\@9F4M;&]B:BYO"B!D;&QI<W0N;R!P<7-I9VYA;"YO('!Q8V]M
M<')I;2YO"G)E;&]C871I;VYS(')E9F5R96YC960*(" @(" @("!F<F]M(&9I
M;&4H<RD*(" @(" @("!F92UA=71H+F\*(" @(" @("!F92UC;VYN96-T+F\*
M(" @(" @("!F92UE>&5C+F\*(" @(" @("!F92UM:7-C+F\*(" @(" @("!F
M92UL;V)J+F\*(" @(" @("!D;&QI<W0N;PH@(" @(" @('!Q<VEG;F%L+F\*
M(" @(" @("!P("!F871A;"!E<G)O
M<CH@(&%G86EN<[email protected];V-A=&%B;&[email protected]
M(&YO;BUW<FET80IB;&4@<V5C=&EO;CH@+G1E>'0*"F=M86ME6S)=.B J*BH@
M6VQI8G!Q+G-O+C%=($5R<F]R(#$*9VUA:V5;,ETZ($QE879I;F<@9&ER96-T
M;W)Y(& O:&]M92]P9W-Q;"]P;W-T9W)E<W%L+38N,RXR+W-R8R]I;G1E<F9A
M8V5S+VQI8G!Q)PIG;6%K95LQ73H@*BHJ(%MA;&Q=($5R<F]R(#(*9VUA:V5;
M,5TZ($QE879I;F<@9&ER96-T;W)Y(& O:&]M92]P9W-Q;"]P;W-T9W)E<W%L
M+38N,RXR+W-R8R]I;G1E($5R<F]R
M(#(*"@I0;&5A<V4@+BX@:&5L<"[email protected]%]4+BXN+BXN+BXN+BX*
M"D=O;V0@;'5C:R!T;R!Y;W4N+BXN"@I0;&5A<[email protected]&5S8W)[email protected]!W87D@
M=&\@<F5P96%T('1H92!P<F]B;&5M+B @(%!L96%S92!T<GD@=&\@<')O=FED
M92!A"F-O;F-I(&%L;"!P
M;W-S:6)L93H*+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
F+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0H*"@HM

end

From scrappy
Date: Tue, 13 Oct 1998 12:28:13 -0500
From: Eric Smith <[email protected]>
Subject: Problem compiling at ecpg

Using Gnu make 3.71, bison 1.22 and flex 2.54a on a sunos4.1.4 system

output from make:
copper# /usr/bin/gmake all
/usr/bin/gmake -C include all
gmake[1]: Entering directory
`/usr/local/postgres/postgresql-6.3.2/src/interface
s/ecpg/include'
Nothing to be done.
gmake[1]: Leaving directory
`/usr/local/postgres/postgresql-6.3.2/src/interfaces
/ecpg/include'
/usr/bin/gmake -C lib all
gmake[1]: Entering directory
`/usr/local/postgres/postgresql-6.3.2/src/interface
s/ecpg/lib'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/usr/local/postgres/postgresql-6.3.2/src/interfaces
/ecpg/lib'
/usr/bin/gmake -C preproc all
gmake[1]: Entering directory
`/usr/local/postgres/postgresql-6.3.2/src/interface
s/ecpg/preproc'
gcc -I../../../include -I../../../backend -Wall -Wmissing-prototypes
- -I../in
clude -DMAJOR_VERSION=1 -DMINOR_VERSION=1 -DPATCHLEVEL=0
- -DINCLUDE_PATH=\"/usr/l
ocal/pgsql/include\" -c pgc.c -o pgc.o
pgc.l:173: warning: no previous prototype for `yylex'
pgc.l: In function `yylex':
pgc.l:72: warning: implicit declaration of function `fprintf'
pgc.l:109: `PATH_MAX' undeclared (first use this function)
pgc.l:109: (Each undeclared identifier is reported only once
pgc.l:109: for each function it appears in.)
pgc.l:109: warning: unused variable `inc_file'
pgc.l:227: warning: implicit declaration of function `fwrite'
pgc.l:236: warning: implicit declaration of function `fclose'
pgc.l:131: warning: label `find_rule' defined but not used
pgc.l: In function `yy_get_next_buffer':
pgc.l:487: warning: implicit declaration of function `_filbuf'
pgc.l:488: warning: implicit declaration of function `fread'
pgc.l: At top level:
pgc.l:1106: warning: `yy_flex_realloc' defined but not used
pgc.l:589: warning: `yyunput' defined but not used
gmake[1]: *** [pgc.o] Error 1
gmake[1]: Leaving directory
`/usr/local/postgres/postgresql-6.3.2/src/interfaces
/ecpg/preproc'
gmake: *** [all] Error 2
Eric Smith
System Manager
Color and Beyond
P: 630-462-4990
F: 630-462-7079
E: [email protected]

From scrappy
Date: Tue, 13 Oct 1998 16:23:29 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: pg_dump'ed script can not load large data

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : alexander smishlajev
Your email address : [email protected]

Category : runtime: front-end
Severity : serious

Summary: pg_dump'ed script can not load large data

System Configuration
- --------------------
Operating System : FreeBSD 2.2.7-stable

PostgreSQL version : 6.3.2

Compiler used : gcc 2.7.2.1

Hardware:
- ---------
FreeBSD tiger.rrc.lv 2.2.7-STABLE FreeBSD 2.2.7-STABLE #0: Tue Oct 13 17:13:54 EEST 1998 [email protected]:/usr/src/sys/compile/TIGER i386

Versions of other tools:
- ------------------------
gmake 3.76.1

- --------------------------------------------------------------------------

Problem Description:
- --------------------
while loading the script produced with pg_dump tool
i've got an error:

query buffer max length of 20000 exceeded
query line ignored


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------
one of possible ways is to make dump directory instead of single script, with each table dumped to separate data file. dump directory may be converted to shar or tar.gz archive, afterwards.

- --------------------------------------------------------------------------

From scrappy
Date: Tue, 13 Oct 1998 16:36:20 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: pg_dump produces non-parsable column default

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : alexander smishlajev
Your email address : [email protected]

Category : runtime: front-end
Severity : non-critical

Summary: pg_dump produces non-parsable column default

System Configuration
- --------------------
Operating System : FreeBSD 2.2.7-stable

PostgreSQL version : 6.3.2

Compiler used : gcc 2.7.2.1

Hardware:
- ---------
uname -a: "FreeBSD tiger.rrc.lv 2.2.7-STABLE
FreeBSD 2.2.7-STABLE #0: Tue Oct 13 17:13:54 EEST 1998
[email protected]:/usr/src/sys/compile/TIGER i386"


Versions of other tools:
- ------------------------
gmake 3.76.1

- --------------------------------------------------------------------------

Problem Description:
- --------------------
my table definition had a following column:

log_date date NOT NULL DEFAULT current_date

pg_dump'ed script made for this column following definition:

log_date date DEFAULT date( 'current'::datetime + '0 sec')

load of such definition with "psql -e db < dump.out"
lead to error message:

ERROR: parser: parse error at or near "'"

the table was not created.


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Tue, 13 Oct 1998 16:47:13 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Regression tests fail on shared library support.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Tim Shelling
Your email address : [email protected]

Category : runtime: back-end
Severity : non-critical

Summary: Regression tests fail on shared library support.

System Configuration
- --------------------
Operating System : FreeBSD 3.0 ELF

PostgreSQL version : 6.3.2

Compiler used : gcc 2.7.2.1, ld 2.9.1

Hardware:
- ---------
P300 or something, 128 MB RAM

Versions of other tools:
- ------------------------
gmake 3.76.1

- --------------------------------------------------------------------------

Problem Description:
- --------------------
Shared library on the ELF version of FreeBSD does not work correctly without some changes to the BSD Makefiles and to the dynaloader.c (bsd.c) file.
I have made a patch from the 6.3.2 release; however it includes the patches on the ftp site. There were two problems. The first was resolved by using
Linux-Elf's Makefile.port file for BSD-Elf's. The trick was to have the Makefile determine ifdef ($(shell objformat)),elf). If so, ld needs to be run
differently, both on the shared libraries and the program executable object files. The second problem is related. Apparently, by default on my system,
symbols are NOT prepended by an underscore. Thus the code in bsd.c/pg_dlsym which prepends the underscore needs to be jumped over.


- --------------------------------------------------------------------------

Test Case:
- ----------
Running the regression tests produced excessive errors in
create_function_2, trigger, misc and others.
After my patches, no erros were found in the above modules.

- --------------------------------------------------------------------------

Solution:
- ---------
Changes to Makefile.bsd and ports/dynaloader/bsd.c. Patch
unfortunately includes prior patches from 6.3.2.
Please send me an email so I can send the full patch to you.

- --------------------------------------------------------------------------

From scrappy
Date: Thu, 15 Oct 1998 11:38:04 -0400 (EDT)
From: toor <[email protected]>
Subject: Bug Report Template

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Ben C. Lesmana
Your email address : [email protected]


System Configuration
- ---------------------
Architecture (example: Intel Pentium) : Intel Pentium

Operating System (example: Linux 2.0.26 ELF) : Linux 2.0.35 ELF
Redhat 5.1

PostgreSQL version (example: PostgreSQL-6.3.2) : PostgreSQL-6.3.2

Compiler used (example: gcc 2.7.2) : gcc 2.7.2.3


Please enter a FULL description of your problem:
- ------------------------------------------------

flex 2.5.4
Bison 1.25

the 4 patches (*98*.patch) that are available has been used.

PostgreSQL failed to compile in my system.
problems from make.log:

gmake[2]: Entering directory `/home/postgres/postgresql-6.3.2/src/backend/bootstrap'
/usr/bin/bison -y -d bootparse.y
grep -v "^#" boot.sed > sedfile
sed -f sedfile < y.tab.c > bootparse.c
mv y.tab.h bootstrap_tokens.h
rm -f y.tab.c sedfile
gcc -I../../include -I../../backend -O2 -g -Wall -Wmissing-prototypes -I.. -W no-error -c bootparse.c -o bootparse.o
/usr/lib/bison.simple: In function `Int_yyparse':
/usr/lib/bison.simple:327: warning: implicit declaration of function `Int_yyerror'
/usr/lib/bison.simple:387: warning: implicit declaration of function `Int_yylex'
flex bootscanner.l
grep -v "^#" boot.sed > sedfile
sed -f sedfile < lex.yy.c > bootscanner.c
rm -f lex.yy.c sedfile
gcc -I../../include -I../../backend -O2 -g -Wall -Wmissing-prototypes -I.. -W no-error -c bootscanner.c -o bootscanner.o
ex.Int_yy.c:683: warning: no previous prototype for `Int_yylex'
bootscanner.l:137: warning: no previous prototype for `Int_yyerror'
gcc -I../../include -I../../backend -O2 -g -Wall -Wmissing-prototypes -I.. -W -no-error -c bootstrap.c -o bootstrap.o
bootstrap.c:160: `F_BOOLIN' undeclared here (not in a function)
bootstrap.c:160: initializer element for `Procid[0].inproc' is not constant
bootstrap.c:160: `F_BOOLOUT' undeclared here (not in a function)
bootstrap.c:160: initializer element for `Procid[0].outproc' is not constant
[Snipped .. lots of them here]
bootstrap.c:178: `F_ARRAY_IN' undeclared here (not in a function)
bootstrap.c:178: initializer element for `Procid[17].inproc' is not constant
bootstrap.c:178: `F_ARRAY_OUT' undeclared here (not in a function)
bootstrap.c:178: initializer element for `Procid[17].outproc' is not constant
gmake[2]: *** [bootstrap.o] Error 1
gmake[2]: Leaving directory `/home/postgres/postgresql-6.3.2/src/backend/bootstrap'
gmake[1]: *** [bootstrap.dir] Error 2
gmake[1]: Leaving directory `/home/postgres/postgresql-6.3.2/src/backend'
gmake: *** [all] Error 2


APlease describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------

gmake clean ; gmake all

If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------

From scrappy
Date: 15 Oct 1998 23:48:27 -0000
From: Peter Rye <[email protected]>
Subject: PostgreSQL-6.3.2 on Linux Alpha

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Peter Rye
Your email address : [email protected]


System Configuration
- ---------------------
Architecture (example: Intel Pentium) : DEC Alpha (SX164)

Operating System (example: Linux 2.0.26 ELF) : Linux, glibc (Kernel 2.1.125)

PostgreSQL version (example: PostgreSQL-6.3.2) : PostgreSQL-6.3.2

Compiler used (example: gcc 2.7.2) : egcs-1.1b


Please enter a FULL description of your problem:
- ------------------------------------------------
Backend terminates with a segfault on some simple "selects".
Details below.


Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------
prye=> \d agga

Table = agga
+----------------------------------+----------------------------------+-------+
+----------------------------------+----------------------------------+-------+
prye=> select * from agga;
a
- -
1
1
4
3
(4 rows)

prye=> select min(a), max(a), sum(a) from agga;
min|max|sum
- ---+---+---
1| 4| 9
(1 row)

prye=> select min(a), max(a), sum(a), avg(a) from agga;
min|max|sum|avg
- ---+---+---+---
1| 4| 9| 2
(1 row)

prye=> select avg(a), min(a), max(a), sum(a) from agga;
PQexec() -- Request was sent to backend, but backend closed the channel before responding.
This probably means the backend terminated abnormally before or while processing the request.

Part of strace of postmaster process:
....
17599 open("/var/lib/pgsql/base/prye/pg_class_oid_index", O_RDWR) = 24
17599 lseek(24, 0, SEEK_END) = 16384
17599 lseek(24, 0, SEEK_SET) = 0
17599 read(24, "\10\0\360\37\360\37\0 b1\5\0\1\0"..., 8192) = 8192
17599 lseek(24, 8192, SEEK_SET) = 8192
17599 read(24, "t\2@\26\360\37\0 `\237 \0P\237 \0"..., 8192) = 8192
17599 lseek(14, 0, SEEK_END) = 8192
17599 lseek(14, 0, SEEK_END) = 8192
17599 brk(0x120310000) = 0x120310000
17599 brk(0x120312000) = 0x120312000
17599 brk(0x120314000) = 0x120314000
17599 --- SIGSEGV (Segmentation fault) ---
17578 <... select resumed> ) = ? ERESTARTNOHAND (To be restarted)
17578 --- SIGCHLD (Child exited) ---
17578 wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], WNOHANG, NULL) = 17599
17578 semget(5432114, 0, 0) = 22272
17578 semctl(22272, 0, IPC_RMID, 0x200000b5120) = 0
.....



If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------
I haven't been able to narrow down the problem any further as yet.
(I'm a bit lost in the source files!)

From scrappy
Date: Fri, 16 Oct 1998 18:34:46 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Make file looks for nonexistant files, documented fix doesn't work.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Regan Pylman
Your email address : [email protected]

Category : install: compile
Severity : serious

Summary: Make file looks for nonexistant files, documented fix doesn't work.

System Configuration
- --------------------
Operating System : FreeBSD 2.2.7

PostgreSQL version : 6.3.2

Compiler used : gcc 2.7

Hardware:
- ---------
FreeBSD coyotesdaughter.com 2.2.7-RELEASE FreeBSD 2.2.7-RELEASE #0: Wed Jul 22
AT&T (NCR) Globalyst 550
CPU: i486 DX2 (486-class CPU)
Origin = "GenuineIntel" Id = 0x435 Stepping=5
Features=0x3<FPU,VME>
real memory = 33554432 (32768K bytes)
avail memory = 30400512 (29688K bytes)

Versions of other tools:
- ------------------------
gmake 3.77
flex 2.5.4

- --------------------------------------------------------------------------

Problem Description:
- --------------------
I downloaded the postgresql-6.3.2.tar.gz, and read the INSTALL directions. I followed them, step by step, until I came to the 'gmake all >& make.log &' instruction. It failed with a 'ELF interpreter /usr/libexec/ld-elf.so.1 not found' error.
The INSTALL documentation suggests getting the elf files from the .../pgsql/lib directories, but there don't seem to /be/ any .../pgsql/lib directories. That directory wasn't included in the zip. Is there a place to get it, or can the .tar.gz file be corrected, please?
(Oh, and yes, I did a 'find /usr -name ld-elf.so.1' -- it doesn't exist on my system.)
Thanks.

- --------------------------------------------------------------------------

Test Case:
- ----------
Just follow the INSTALL instructions. You'll soon go wrong.

- --------------------------------------------------------------------------

Solution:
- ---------
Correcting the documentation would probably be a good start, followed by actually distributing what the documentation says you're distributing.

- --------------------------------------------------------------------------

From scrappy
Date: Mon, 19 Oct 1998 09:36:39 -0400
From: Jim Dossey <[email protected]>
Subject: compile report

I just wanted to let you know that postgresql 6.4 beta 2 compiles
cleanly on SCO Unixware 7.0.1. It did have one typo in the Makefile in
interfaces/ecpg/lib, but it was a simple fix that I'm sure will be fixed
in the next release. The regression tests had a lot of errors mainly
due to differences in error messages and floating point precision.
There were some errors in the regression tests having to do with
geometric shapes, but I haven't really looked into those yet.
- --
- -----------------------------------------------------------------------
Jim Dossey mailto:[email protected]

From scrappy
Date: Mon, 19 Oct 1998 15:10:36 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Suggested change in wording for pg_dumpall man page

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Darren Stuart Embry
Your email address : [email protected]

Category : unknown
Severity : non-critical

Summary: Suggested change in wording for pg_dumpall man page

System Configuration
- --------------------
Operating System : n/a

PostgreSQL version : 6.3.2

Compiler used : n/a

Hardware:
- ---------
n/a

Versions of other tools:
- ------------------------
n/a

- --------------------------------------------------------------------------

Problem Description:
- --------------------
This is a suggested change for the documentation and not,
the software itself, hence all the n/a's I filled out on
the bug report form. :)

The wording "pg_dumpall creates each dumped database
before loading." is confusing. A more accurate wording
would probably be "the output produced by pg_dumpall
creates each dumped database before loading."

If there is a more appropriate way to report bugs and
annoyances in the documentation, then please let me know.

Thanks,
Darren

- --------------------------------------------------------------------------

Test Case:
- ----------
man pg_dumpall. :)

- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Tue, 20 Oct 1998 09:45:32 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: yacc blows up in backends/parser

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Hugh Brower
Your email address : [email protected]

Category : install: compile
Severity : critical

Summary: yacc blows up in backends/parser

System Configuration
- --------------------
Operating System : BSDI 3.1 and 4.0

PostgreSQL version : 6.3.2

Compiler used : gcc version 2.7.2.1

Hardware:
- ---------
Pentium 233, 48 MB RAM, 24 MB available
BSD/OS 4.0 BSDI BSD/OS 4.0 Kernel #0: Tue Jul 28 15:56:54 M
DT 1998 [email protected]:/rel/proto/4.0-i386/usr/src/sys/compile/GENERIC i386

Versions of other tools:
- ------------------------
GNU Make version 3.75
lex version 2.5.4
no way to determinine version of yacc

- --------------------------------------------------------------------------

Problem Description:
- --------------------
Error is:
/usr/bin/yacc -d gram.y
/usr/bin/yacc: f - maximum table size exceeded

It occurs on both BSDI 3.1 and 4.0
I've tried both TCSH and plain SH shells for the compile.


- --------------------------------------------------------------------------

Test Case:
- ----------
just 'make all' does the trick.

- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Tue, 20 Oct 1998 21:12:16 -0500
From: "Frank Griffith" <[email protected]>
Subject: Problem installing postgresql-6.3.2 on FreeBSD 2.2.7

As per your instructions, form is attached.


begin 666 postgres.txt
[email protected]&]S=&=R95-13"!F86EL960@=&\@8V]M<&EL92!O;B!Y;W5R(&-O;7!U
M=&5R(&]R('EO=2!F;W5N9"!A(&)U9R!T:&%T#0II<R!L:6ME;'D@=&\@8F4@
M<W!E8VEF:6,@=&\@;VYE('!L871F;W)M('1H96X@<&QE87-E(&9I;&P@;W5T
M('1H:7,@9F]R;0T*86YD(&4M;6%I;"!I="!T;R!P9W-Q;"UP;W)T<T!P;W-T
M9W)E<W%L+F]R9RX-"@T*5&\@<F5P;W)T(&%N>2!O=&AE<B!B=6<L(&9I;&P@
M;W5T('1H92!F;W)M(&)E;&]W(&%N9"!E+6UA:6P@:70@=&\-"G!G<W%L+6)U
M9W- <&]S=&=R97-Q;"YO<F<N#0H-"DEF('EO=2!N;W0@;VYL>2!F;W5N9"!T
M:&4@(&%N9"!G96YE<F%[email protected]!P871C
M: T*=&AE;B!E+6UA:6P@:70@=&\@<&=S<6PM<&%T8VAE<T!P;W-T9W)E<W%L
M+F]R9R!I;G-T96%D+B @4&QE87-E('5S92!T:&4-"F-O;6UA;F0@(F1I9F8@
M+6,B('1O(&=E;F5R871E('1H92!P871C:"X-"@T*66]U(&UA>2!A;'-O(&5N
M=&5R(&$@8G5G(')E<&]R="!A="!H='1P.B\O=W=W+G!O<W1G<F5S<6PN;W)G
M+R!I;G-T96%D(&]F#0IE+6UA:6PM:6YG('1H:7,@9F]R;2X-"@T*/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0T*(" @(" @(" @(" @(" @(" @
M(" @(" @4$]35$=215-13"!"54<@4D503U)4(%1%35!,051%#0H]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]#0H-"@T*66]U<B!N86UE"0DZ"49R
M86YK($=R:69F:71H#0I9;W5R(&5M86EL(&%D9')E<W,)[email protected]<F%N:V= :61F
M=RYC;VT-"@T*#0I3>[email protected]]N9FEG=7)A=&EO;@T*+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM#0H@($%R8VAI=&5C='5R92 H97AA;[email protected]@4&5N
M=&EU;2D@( DZ($EN=&5L(%!E;G1I=6T@,38V#0H-"B @3W!E<F%T:6YG(%-Y
M<W1E;2 H97AA;7[email protected]&EN=7@@,BXP+C(V($5,1BD@"[email protected])E94)31" R
M+C(N-PT*#0H@(%!O<W1G<F5344P@=F5R<VEO;B H97AA;[email protected]&]S=&=R
M95-13"TV+C,N,BD@(#H@("!0;W-T9W)E4U%,+38N,RXR#0H-"B @0V]M<&EL
M97(@=7-E9" H97AA;7!L93H@(&=C8R R+C<N,BD)"3H)0V%M92!W+T9"4T0@
M,BXR+C<-"@T*#0I0;&5A(@82!&54Q,(&1E<V-R:7!T:6]N(&]F
M('EO=7(@<')O8FQE;3H-"BTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+0T*22!E;G1E<B!T:&4@<F5G<F5S<VEO;B!T
M97-T(&]F('1H92!D;V-S(&%N9"!W:&5N($D@<W1A<G0@<&]S=&UA<W1E<@T*
M=&AE(&-U<G-O<B!D<F]P<R!D;W=N(&$@;&EN92!A;F0@;F]T:&EN9R!H87!P
M96YS+B!)(&AA=F4@=V%I=&5D(&9O<B -"F%S(&QO;F<@87,@,C @;6EN=71E
M<R!F;W(@:70@=&\@(&)U="!N;R!D:6-E
[email protected]*#0I)('=E;G0@=&AR;W5G:"!T:&4@:6YS=')U8W1I;VYS(&-A<F5F=6QL
M>[email protected]!W87,@8V][email protected]@=&AE( T*:6YS=')U8W1I;VYS(&EN('-T
M97 @(S$T+" B5&5L;"!5;FEX(&AO=R!T;R!F:6YD('EO=7(@<VAA<F5D(&QI
M8G)A('1H:7,@[email protected]
M=&EN9R!T:&4@+G!R;V9I;&[email protected]!I;B!T:&4@#0HO:&]M92]P;W-T9W)E
M<R!D:7)E8W1O<GDN($[email protected]@=&AE(&QI;F5S(&QI<W1E9"!I;B!S=&5P
M(#$U(&%N9" -"F%L<V\@861D960@=&AI<R!L:[email protected]*#0H)3$1?3$E"4D%2
M65]0051(/2]U<W(O;&]C86PO<&=S<6PO;&EB#0H)97AP;W)T(%!!5$@@34%.
M4$%42"!01TQ)0B!01T1!5$$@3$1?3$E"4D%265]0051(#0H-"FEN:71D8B!R
M86X@;VMA>2P@;F\@<')O8FQE;2!S965M960@=&\@:&%P<&5N<R!H97)E+B!)
M(&QE9G0@=&AE(&9I;&4@#0HO=7-R+VQO8V%L+W!G<W%L+V1A=&$O<&=?:&)A
M+F-O;F8@:6YT86-T(&%F=&5R(&QO;VMI;F<@870@:70L(&9I9W5R:6YG( T*
M=&AE(&QA('=E($D@;F5E9&5D+B!.
M;R!N965D(&9O<B!S=7!E<B!S96-U<FET>2 -"F%T('1H:7,@<&]I;G0N($EN
M('-T97 @(S$X('=A<R!W:&5R92!)('-N86=G960@=7 N#0H-"@T*4&QE87-E
M(&1E(')E<&5A="!T:&4@<')O8FQE;2X@("!0;&5A
M('!R;W9I9&[email protected]*8V]N8VES92!R97!R;V1U8VEB;&[email protected]
M;7!L92P@:[email protected]@86QL('!O<W-I8FQE.B -"BTM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2T-"D=O('1H<F]U9V@@=&AE(&EN<W1R=6-T:6]N<R!O;B!A($9R
M965"4T0@,BXR+C<@8V]M(&AO
M=R!T:&ES('!R;V)L96T@;6EG:'[email protected]@9FEX960L(&QI('-O;'5T
M:6]N(&)E;&][email protected]*+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
J+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0H-"@T*
`
end

From scrappy
Date: Wed, 21 Oct 1998 02:38:49 -0400
From: "Carilda A. Thomas" <[email protected]>
Subject: [Fwd: pgsql-ports-digest V1 #146]
FreeBSD has a different way of announcing shared library locations from that of Sys V-based Unixes. Check your man page for "ldconfig". You must be root to run ldconfig in its "add" mode. I seem to recall that the man page says that ldconfig builds a "hints" table, but
these are not "hints", they are a map of full pathnames to the required libraries. Just because, say, /usr/local/lib is on your system, the executor will NOT pick up a new .so you add to /usr/local/lib. You must specifically run

#> ldconfig -a /usr/local/lib

each time you add a new .so to it so the table can be rebuilt.

Be sure that at boot time, you are picking up the full complement of shared library locations. I no longer have an available FreeBSD system to check on, but look at your boot scripts, maybe grep for "ldconfig" or "/usr/lib" to find the boot script that sets up the shared
library table.

Enjoy!

cat
From scrappy
Date: Wed, 21 Oct 1998 15:41:47 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report:

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Darrell Long
Your email address : [email protected]

Category : unknown
Severity : non-critical

Summary:

System Configuration
- --------------------
Operating System : Solaris x85

PostgreSQL version : 6.0

Compiler used :

Hardware:
- ---------


Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
Addendum: I got it to build using the gcc template, but not the native cc one.


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Thu, 22 Oct 1998 22:59:26 -0500
From: Raul Palma <[email protected]>
Subject: Successfully installation of postgres in my system

Postgres v6.3.2
FreeBSD 2.2.6
Laptop Acer TravelMate Pentium 200 Mhz MMX

we compiled, installed and ran the regression tests cleanly.
Tested failed:
numerology
random
float8
geometry

From scrappy
Date: Fri, 23 Oct 1998 05:47:29 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report:

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name :
Your email address :

Category : unknown
Severity : non-critical

Summary:

System Configuration
- --------------------
Operating System :

PostgreSQL version : 6.0

Compiler used :

Hardware:
- ---------


Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Fri, 23 Oct 1998 22:47:49 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: in a game of Hearts and it said my system was whacked and to report it

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : amy moses
Your email address : [email protected]

Category : unknown
Severity : non-critical

Summary: in a game of Hearts and it said my system was whacked and to report it

System Configuration
- --------------------
Operating System : GTE

PostgreSQL version : 6.0

Compiler used :

Hardware:
- ---------


Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Sat, 24 Oct 1998 10:55:03 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: will not compile on Alpha Linux

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Doug Babst
Your email address : [email protected]

Category : install: compile
Severity : serious

Summary: will not compile on Alpha Linux

System Configuration
- --------------------
Operating System : Linux Alpha - RH 5.0

PostgreSQL version : 6.4b2

Compiler used : gcc 2.7.3.2

Hardware:
- ---------
Linux brain.tcgcs.com 2.0.30 #3 Sat Mar 7 05:07:13 CST 1998 alpha unknown
Digital Alpha 433a
64Mb RAM

Versions of other tools:
- ------------------------
GNU Make version 3.76.1, by Richard Stallman and Roland McGrath.
flex version 2.5.4

- --------------------------------------------------------------------------

Problem Description:
- --------------------
I'm including a sample of errors in the gmake.log. I can
provide the full file if needed.

We start off with a little of this:
- ------------
hashutil.c: In function `_hash_call':
hashutil.c:103: warning: cast from pointer to integer of different size
ld -r -o SUBSYS.o hash.o hashfunc.o hashinsert.o hashovfl.o hashpage.o hashscan.o hashsearch.o hashs
trat.o hashutil.o
- ------------
which seems to show up quite a bit, but doesn't seem to hurt much.

And then this:
- ------------
gcc -I../../include -I../../backend -O2 -mieee -Wall -Wmissing-prototypes -I.. -Wno-error -c bo
otparse.c -o bootparse.o
/usr/lib/bison.simple: In function `Int_yyparse':
/usr/lib/bison.simple:327: warning: implicit declaration of function `Int_yyerror'
/usr/lib/bison.simple:387: warning: implicit declaration of function `Int_yylex'
flex bootscanner.l
- ------------

And this:
- ------------
gcc -I../../include -I../../backend -O2 -mieee -Wall -Wmissing-prototypes -I.. -c command.c -o
command.o
command.c: In function `PerformPortalFetch':
command.c:156: warning: type mismatch in implicit declaration for built-in function `memcpy'
- ------------

This one goes on for a couple of pages:
- ------------
outfuncs.c: In function `_outIntList':
outfuncs.c:68: warning: cast from pointer to integer of different size
outfuncs.c: In function `_outHashJoin':
outfuncs.c:433: warning: cast from pointer to integer of different size
- ------------

This one too:
- ------------
plancat.c: In function `restriction_selectivity':
plancat.c:336: warning: cast to pointer from integer of different size
plancat.c:337: warning: cast to pointer from integer of different size
plancat.c:338: warning: cast to pointer from integer of different size
plancat.c:340: warning: cast to pointer from integer of different size
- ------------

This is the error that seems to take everything down:
- ------------
gcc -I../../../include -I../../../backend -O2 -mieee -Wall -Wmissing-prototypes -I../.. -c bufm
gr.c -o bufmgr.o
/tmp/cca06722.s: Assembler messages:
/tmp/cca06722.s:792: Fatal error: Symbol success already defined.
gmake[3]: *** [bufmgr.o] Error 1
- ------------

And eventually it all breaks down to this repeating:
- ------------
for i in buffer file ipc large_object lmgr page smgr; do gmake -C $i buffer/SUBSYS.o; done
gmake[3]: Entering directory `/u3/comp/database/postgresql/postgresql-6.4-Beta2/src/backend/storage/
buffer'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory `/u3/comp/database/postgresql/postgresql-6.4-Beta2/src/backend/storage/b
uffer'
gmake[3]: Entering directory `/u3/comp/database/postgresql/postgresql-6.4-Beta2/src/backend/storage/
file'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
- ------------


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------
There was a patch available to let 6.3.2 compile on the
Alpha, I just don't have time to work with it right now and
it would be nice to have this in the 6.4 final if possible.

I can provide access to my Alpha if it would help.

- --------------------------------------------------------------------------

From scrappy
Date: Sat, 24 Oct 1998 22:36:34 -0400 (EDT)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Spinlocks are incorrectly implimented

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Christopher Collins
Your email address : [email protected]

Category : install: compile
Severity : critical

Summary: Spinlocks are incorrectly implimented

System Configuration
- --------------------
Operating System : NetBSD/pmax 1.3.2

PostgreSQL version : 6.2

Compiler used : 2.7.2.2+myc1


Hardware:
- ---------
DECstation 5000/240, 32MB RAM
uname -a output:
NetBSD holodec.anu.edu.au 1.3.2 NetBSD 1.3.2 (HOLODEC) #0: Fri Sep 11 00:57:19 PDT 1998 roo[email protected]:/usr/src/sys/arch/pmax/compile/HOLODEC pmax


Versions of other tools:
- ------------------------
gmake version 3.77

- --------------------------------------------------------------------------

Problem Description:
- --------------------
Spinlocks aren't correctly implimented on this platform.
It results in the symbols SPIN_* not being defined properly. [and in most cases, not being defined at all]


- --------------------------------------------------------------------------

Test Case:
- ----------
reproducible by ./configure; make
using either generic, netbsd or ultrix4 as the target architecture
[since postgresSQl doesn't recognise mips-dec-netbsd]


- --------------------------------------------------------------------------

Solution:
- ---------
Fix Spinlocks

- --------------------------------------------------------------------------

From scrappy
Date: Mon, 26 Oct 1998 18:00:08 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report:

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name :
Your email address :

Category : unknown
Severity : non-critical

Summary:

System Configuration
- --------------------
Operating System :

PostgreSQL version : 6.0

Compiler used :

Hardware:
- ---------


Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------


- --------------------------------------------------------------------------

Test Case:
- ----------


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Wed, 28 Oct 1998 07:44:55 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Error "cannot extend" on COPY of 125,000 small rows.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : David Quinn-Jacobs
Your email address : [email protected]

Category : runtime: back-end: SQL
Severity : critical

Summary: Error "cannot extend" on COPY of 125,000 small rows.

System Configuration
- --------------------
Operating System : Linux 2.x (Redhat 5)

PostgreSQL version : 6.3.2

Compiler used : gcc 2.7.2.3

Hardware:
- ---------
Linux dante 2.0.31 #1 Sun Nov 9 21:45:23 EST 1997 i586 unknown

Versions of other tools:
- ------------------------
gmake 3.76.1

- --------------------------------------------------------------------------

Problem Description:
- --------------------
Using a COPY statement into a small table fails on trying to load 125,000 rows from a file. Table defnn:
CREATE TABLE Stocks (
tradingDate date,
symbol char(10),
open float8,
high float8,
low float8,
atClose float8,
volume float8
);

- --------------------------------------------------------------------------

Test Case:
- ----------
Have had the same problem with several different data sources.

- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Thu, 29 Oct 1998 14:01:56 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Deadlock problem using transactions

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Stephane Alnet
Your email address : [email protected]

Category : runtime: back-end: SQL
Severity : non-critical

Summary: Deadlock problem using transactions

System Configuration
- --------------------
Operating System : Linux 2.1

PostgreSQL version : 6.3

Compiler used : gcc

Hardware:
- ---------
Not hardware related

Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
One cannot use the database when two concurrent transactions are opened.
For example, an insert waits until all other transactions are closed, or dies with a lock-related error.
Actually, the first opened transactions locks all other transactions until it finished.

- --------------------------------------------------------------------------

Test Case:
- ----------
(1) begin transaction;
(2) begin transaction;
(2) insert into a values (7); (locked)
(1) end transaction; -> proceed with insert
(table "a" is a dummy table with one integer column)

- --------------------------------------------------------------------------

Solution:
- ---------
Time travel would provide a simple solution (all operations during the transaction are timestamped with the time of the "begin transaction" and no one has to care about updates arriving during the transaction).
I supposed that after time travel has been removed there would be something else taking care of that?

- --------------------------------------------------------------------------

From scrappy
Date: Fri, 30 Oct 1998 10:42:52 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: currval() not valid until nextval() called.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Anthony Howe
Your email address : [email protected]

Category : runtime: back-end
Severity : non-critical

Summary: currval() not valid until nextval() called.

System Configuration
- --------------------
Operating System : Linux 2.0.34

PostgreSQL version : 6.3.2

Compiler used : gcc

Hardware:
- ---------
RedHat 5.1

Versions of other tools:
- ------------------------


- --------------------------------------------------------------------------

Problem Description:
- --------------------
In trying to write a web page that displays what the next
inserted record _will_ be, I wanted to use currval() to
query the sequence and display as information in a form
prior to the 'insert'.

However during interactive testing with psql, I kept
getting :

ERROR: code.currval is not yet defined in this session

It would appear that currval() is not the same as saying :

SELECT last_value FROM code;

where code is a sequence. The above SQL works regardless,
but would appear to be less portable.



- --------------------------------------------------------------------------

Test Case:
- ----------
create sequence code start 50;
select currval('code') as bogus;
select last_value from code;
select nextval('code') as bump;
select currval('code') as here_and_now;


- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------

From scrappy
Date: Fri, 30 Oct 1998 19:37:00 -0600 (CST)
From: Ryan Kirkpatrick <[email protected]>
Subject: Linux/Alpha Regression tests....

Ok, here is a run down on the regression tests for
pgsql snapshot (09271998) on Linux/Alpha:

int2 .. failed - Difference in error messages. (ok)
int4 .. failed - Wrapped number when should have errored. (ok)
float4 .. failed - Overflow and underflow numbers rounded to inf and
9.99999E-40 when error message should have resulted.
(ok)
float8 .. failed - Same as above. (ok)
numerology .. failed - First same as int4, then a backend failure.
(Problem?)
geometry .. failed - Off by one in nth decimal place. (ok)
datetime .. failed - Problems with adding time to 'today'. (Problem!)
reltime .. failed - More time calculation failures. (Problem!)
abstime .. failed - All dates a long way off, by a few hundred years.
(PROBLEM!)
tinterval .. failed - Same as above. (PROBLEM!)
horology .. failed - Same as above. (PROBLEM!)
select_having .. failed - Backend failure, probably memory violation.
(Problem)
union .. failed - Same as int4. (ok)
random .. failed - Failure on a type and oid, wierd. (Problem?)
misc .. failed - More wierd errors. :( (Problem?)

It appears most of the problems are concentrated in the datetime
code, and the rest of the problems are cascade failures from trying to use
the faulty datetime functions for more extensive tests. There are a few
other problems (i.e. select_having), but I feel that the datetime stuff
needs to be sorted out first.
I have tried to figure out what is up with the datetime code many
times, but always ended in a dead end. Any test programs I write to see if
I can isolate the problem work fine. Any attempts at debugging are
fruitless as gdb is not 100% stable on Linux/Alpha and gets lost sometimes
(returning random values for memory address! :( ).
What I have been able to track down that any call to localtime()
library call is returning a date at some point in the year 2136! The
system clock is correct. localtime() does conversion between time formats
and somewhere it is getting its feet stepped on. Date time data going in
is fine, but coming out it is scrambled. Test programs that just run data
through localtime() work just fine.
Also, this only seems to happen when 'today' (if I
remember correctly) is used for datetime input. Actual dates seem to work
just fine though.
The biggest trouble in finding this bug is how "complex" the
datetime code is... Actually after hacking at it for a few hours (with no
success) I have other words to describe it, but I will refrain. :) Might
some one explain to me what exactly is happening in the datetime code so I
might have some idea what is going on. I am relatively good at C, but even
this tests my skills pretty good.
As I find time, I will work further to resolve these problems. If
any one else has any ideas or advice on how to solve this problem, please
send them my way!

PS. If some of this appears vague, it is. I have not had time to
hack recently on pgsql thanks to too much schoolwork. :( Just with the 6.4
release going out soon, I though I better see what help I could find...

PPS. Patch for pgsql snapshots to compile on Linux/Alpha are
coming shortly.

- ----------------------------------------------------------------------------
- ----------------------------------------------------------------------------

From scrappy
Date: Fri, 30 Oct 1998 19:53:28 -0600 (CST)
From: Ryan Kirkpatrick <[email protected]>
Subject: Patches for Pgsql on Linux/Alpha (RE: Last Call...)

Ok, here they are, the long awaited patches to make pgsql compile
once again on Linux/Alpha. It turned out that our old friend S_LOCK was
the problem. Apparently some one had pulled the S_LOCK assembly code out
of the static function that I put it in, and attempted to make it inlined
again (which is what broke it the first time around). On a whim, I
searched the net looking for an Alpha Assembly Programmer's Manual, and
see if it would help me any. I was lucky on both accounts. I found the
manual, and quickly figured out to make local labels. So... The S_LOCK
code for Linux/Alpha is finally safe for inlining! :)
Here is the patch for ./pgsql/src/include/storage/s_lock.h

89c87
< bne $0, already_set \n\
- ---
91c89
< bne $0, already_set \n\
- ---
94,95c92,93
< beq $0, stqc_fail \n\
< success: bis $31, $31, %1 \n\
- ---
97,100c95,98
< jmp $31, end \n\
< stqc_fail: or $31, 1, $0 \n\
< already_set: bis $0, $0, %1 \n\
< end: nop ": "=m"(*lock), "=r"(_res): :"0");
- ---
Though there are two other catches at the moment in compiling
pgsql on Alpha as well:

1. The optimization flag, -O2, that is used, causes some code to
fail to compile with very strange errors, and it causes s_locks to jam.
Apparently this is due to the (somewhat) unstable nature of gcc/egcs on
Alphas at the moment. Turning it down to -O1 solves the problem and
everything works fine.

2. C++ is pretty much broken on Linux/Alpha (Debian 2.0 at least),
due to missing header files. This means that libpq++ can't be compiled.
Either tell configure not to detect/use C++, or comment out the line in
interfaces/Makefile that causes libpq++ to be built.

Beyond that, it should compile, install, and initdb just fine.
Regressions tests are a mixed bag at this time (see my seperate message
concerning this), but look promising.
Here is the specs on my machine for reference:

XL366 Alpha w/192MB of RAM
Debian 2.0 Alpha (unstable)
Linux 2.0.34
gcc 2.91.57-5
glibc 2.0.7t-1

I would be very interested in regression tests/results from
people running RedHat on thier Alphas. Would help me to narrow down what
is causing some of the regression test problems. If you do send them to
me, make sure to include what kernel, gcc, and glibc you are using.
Thanks.

Ok, that should pretty much cover it for the 6.4 release on the
Linux/Alpha end. I would mark it as working, but still in need of further
work. TTYAL.

- ----------------------------------------------------------------------------
- ----------------------------------------------------------------------------

From scrappy
Date: Fri, 30 Oct 1998 21:15:01 -0500 (EST)
From: Bruce Momjian <[email protected]>
Subject: Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)
I have applied this. However, we normally prefer context diffs.
Fortunately, this patch had old and new rows, so it was almost the same
as a context diff.

It also only dealt with the alpha locking code, which he stated was
clearly broken, so application seemed good. Some of your more agressive
patches may have to wait a week until 6.4 is released.

- --
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

From scrappy
Date: Sat, 31 Oct 1998 03:32:57 +0000
From: "Thomas G. Lockhart" <[email protected]>
Subject: Re: [PORTS] Linux/Alpha Regression tests....
I'll assume it would be a compliment :) I was happy with how simple I
was able to make the code. Date/time stuff ain't easy.

I'm guessing that the problem is in one of two areas:

1) the configure/build process is confused as to what kind of time
support you have on your system. There are two styles of local time
conversion interfaces on Unix systems: one which uses global variables
to return info on time zones, and one which returns that info as part of
the tz structure. The third type, which is pretty much no timezone
support, is probably not relevant, though if your system is really
confused you should eliminate that as a possibility. The second type is
reentrant, the first is not. It doesn't really matter which kind your
system uses because each backend is essentially single-threaded, but if
it guesses wrong on what kind of system you have then the results will
be garbage.

2) the Postgres code stomps on the global variables used for timezone
info. I think I got that resolved, but I figured I should mention it
just in case.

It is most likely that (1) is the problem. Try compiling with
"-DDATEDEBUG" specified, and see if that helps you track through the
code. Though it seems like you already know where the problem is
located, so I'd just pound on an example until you get it figured out.

Good luck.

- Tom

From scrappy
Date: Fri, 30 Oct 1998 22:52:25 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: syntax error during 'initdb' call

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Brannen Hough
Your email address : [email protected]

Category : install: other
Severity : critical

Summary: syntax error during 'initdb' call

System Configuration
- --------------------
Operating System : Linux2.0.35Elf-RH5.1)

PostgreSQL version : 6.4B4

Compiler used : GCC 2.7.2.3

Hardware:
- ---------
Pentium 166, 48M RAM, Linux
Linux Bane 2.0.35 #10 Thu Oct 15 23:23:30 EDT 1998 i586 unknown

Versions of other tools:
- ------------------------
gmake 3.76.1,

- --------------------------------------------------------------------------

Problem Description:
- --------------------
Build and install went smoothly - new install, not update.
'initdb', when run, generates this output:
"initdb: using /usr/local/pgsql/lib/local1_template1.bki.source as input to create the template database.
initdb: using /usr/local/pgsql/lib/global1.bki.source as input to create the global classes.
initdb: using /usr/local/pgsql/lib/pg_hba.conf.sample as the host-based authentication control file.

We are initializing the database system with username postgres (uid=100).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /usr/local/pgsql/data

Creating Postgres database system directory /usr/local/pgsql/data/base

initdb: creating template database in /usr/local/pgsql/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
syntax error 2299 : parse error
Creating global classes in /base
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
Adding template1 database to pg_database...
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1 < /tmp/create.774
ERROR: pg_atoi: error in "template1": can't parse "template1"
ERROR: pg_atoi: error in "template1": can't parse "template1"
initdb: could not log template database
initdb: cleaning up."

- --------------------------------------------------------------------------

Test Case:
- ----------
Tried every combination of things I could think of - same
error every time 'initdb' is run, so is very repeatable.
Worked on it a few hours today, but couldn't find a cause
or way around it.

- --------------------------------------------------------------------------

Solution:
- ---------


- --------------------------------------------------------------------------