On Tue, 30 Dec 1997, Bruce Momjian wrote:

Can someone remind me why it can not be defined as as a macro like all
the other ones? It is the label in the asm? Don't others have it?
The reason that S_LOCK must be a seperate function is because for
some reason alpha assembly code does not like local labels. Actually local
labels work just fine, but even when the same piece of assembly code with
local labels is included more than once in a .c file, redefintions occur.
Apprently the way that alpha assembly is structured, all labels must be
unique globally in atleast that object file if not the entire binary.
There may be another way to do this, with a macro, but it wil require very
"deep magic" that no one seems to know. Probably only the designers at Dec
know. If someone wants to ask them for help, and get this problem more
elegantly solved, be my guest. But until such a solution appears, I
suggest we stick with the current solution. It works, and it is not all
that horrible. I hope that answers your question.

- ----------------------------------------------------------------------------
"For to me to live is Christ, and to die is gain." |
--- Philippians 1:21 (KJV) |
- ----------------------------------------------------------------------------
Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
- ----------------------------------------------------------------------------
http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
- ----------------------------------------------------------------------------

From scrappy
Date: Thu, 1 Jan 1998 15:17:06 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: LibPQ Malloc Error in PQexec

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


Your name : Jay W. Summet
Your email address : jay@summet.com

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

Summary: LibPQ Malloc Error in PQexec

System Configuration
- --------------------
Operating System : BSDI 3.1

PostgreSQL version : 6.2.1

Compiler used : GCC

Hardware:
- ---------
Pentium, 64MB Ram,
uname -a
BSD/OS fnord.nwinfo.net 3.1 BSDI BSD/OS 3.1 Kernel #4: Thu Oct 16 16:16:52 MDT 1
997 polk@corp.BSDI.COM:/amd/demiurge/home/polk/sys-3.0patches/compile/GENERI
C i386

Versions of other tools:
- ------------------------
Flex, Gmake

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

Problem Description:
- --------------------
I have a table as follows:
+----------------------------------+----------------------------------+-------+
Field | Type | Length|
+----------------------------------+----------------------------------+-------+
username | text | var |
linkflag | int4 | 4 |
parent | text | var |
realname | text | var |
address1 | text | var |
address2 | text | var |
phonenumber | text | var |
dateofbirth | text | var |
mmname | text | var |
class | int4 | 4 |
days | int4 | 4 |
autorenew | int4 | 4 |
note | text | var |
payamount | text | var |
payfor | text | var |
specialnote | text | var |
suspendflag | int4 | 4 |
notifydays | int4 | 4 |
+----------------------------------+----------------------------------+-------+

Which has about 1400 rows currently in it. For some reason,
when I run the sql command:
SELECT linkflag FROM accounts WHERE username= "12charname";
from PQexec, I get a segmentation fault with the following
stracktrace: (using GDB)

Program received signal SIGSEGV, Segmentation fault.
0x2bbfc in malloc ()
(gdb) bt
#0 0x2bbfc in malloc ()
#1 0x84f4 in getTuple ()
#2 0x8aea in makePGresult ()
#3 0x91f4 in process_response_from_backend ()
#4 0x943b in PQexec ()
#5 0x5b76 in AGetInt ()
#6 0x59b5 in AGetLink ()
#7 0x3af6 in DisplayGenericInfo ()
#8 0x13c5 in ViewAccount ()
#9 0x1285 in main ()
(gdb)

NOTE: I can run the same query from psql manually and it
works just fine. This ALLWAYS happens when runing it from my
billing program, an easy to use interface into the database.

It appears that this only happens when the username is
exactally 12 characters long. (11 characters works, so does 13)

My functions, AGetInt and AGetLinkflag both work for
usernames of other lengths. (I have included the source for
these two functions later on...)

My question: How do I keep this from happening?
We currently only have 3 users with usernames of 12 characters
and we COULD force them to change their username, and then
not allow any 12 character usernames, but I feel that there
should be a solution to this problem.

Thanks,
Jay W. Summet

Source Code for my two functions follows:

/* int AGetLink(char * username) - Returns the integer Linked flag for the
account associated with the specified username. */

int AGetLink(char* username)
{
return(AGetInt(username,"linkflag"));
}

/*int AGetInt(char* username,char* field) - All of the AGet... functions
that get integer values use a generic “AGetInt” function. This function
takes the name of the field to retrive the data from, and returns an
integer that contains the value. */


int AGetInt(char* username, char* field)
{
PGresult* res; /* we store our result here */
int returnvalue;
char query[500]; /* build our query here */
char* temp; /* used to old pointer to answer for a while */

/* Make sure that the connection is still open */
CheckConnection();

/* build the query string */
/* SELECT field FROM accounts WHERE username='username'; */
strcpy(query,"SELECT ");
strcat(query,field);
strcat(query," FROM accounts WHERE username = '");
strcat(query,username);
strcat(query,"';");

/* get a tuple */
res = PQexec(conn,query);
if (PQresultStatus(res) != PGRES_TUPLES_OK) {
PQclear(res);
PQfinish(conn); /* close connection */
printf("Database.c: AGetInt Failure!\n");
exit(1);
}

/* we should ALWAYS have a single unique answer */
if ( 1 != PQntuples(res) )
{
fprintf(stderr,"Database.c: AGetInt: Answer Not Unique");
exit(1);
}
temp =(char*) PQgetvalue(res,0,0); /* 0,0 for a single unique answer */


returnvalue = atoi(temp);


/* should PQclear PGresult whenever it is no longer needed to
avoid memory leaks */
PQclear(res);

return(returnvalue);
} /* end AGetInt */


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

Test Case:
- ----------
I can repeat it any time I try to view a user whose
name has exactally 12 characters. (specifically, when
the program tries to access the linkflag value) usually
the first Integer value.

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

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


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

From scrappy
Date: Thu, 1 Jan 1998 16:18:52 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Test and Set fixed for Linux/Alpha!
On Wed, 31 Dec 1997, Ryan Kirkpatrick wrote:

Ok, I will test it in a week or so and tell you my results. Thanks
for the quick response to the patch. Though
one thing, I only started playing with CVS a few days ago on my own local
machines, so I still a bit of a newbie at this CVS thing. I can figure out
how to get cvs files from across the net from the man/info pages just
fine. Only question I have is what host do I connect to, and do I need a
login or is there a public user that can be used? For the moment I only
need read only access to the CVS tree. If this is all documented
somewhere, then just point me there and I will figure it out. Thanks.
You can't access the CVS repository remotely (unless you have login access
to the server)...except using CVSup...see ftp.postgresql.org:/pub/CVSup for
more details

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 1 Jan 1998 15:32:20 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Test and Set fixed for Linux/Alpha!
On Tue, 30 Dec 1997, Bruce Momjian wrote:

Can someone remind me why it can not be defined as as a macro like all
the other ones? It is the label in the asm? Don't others have it?
The reason that S_LOCK must be a seperate function is because for
some reason alpha assembly code does not like local labels. Actually local
labels work just fine, but even when the same piece of assembly code with
local labels is included more than once in a .c file, redefintions occur.
Apprently the way that alpha assembly is structured, all labels must be
unique globally in atleast that object file if not the entire binary.
There may be another way to do this, with a macro, but it wil require very
"deep magic" that no one seems to know. Probably only the designers at Dec
know. If someone wants to ask them for help, and get this problem more
elegantly solved, be my guest. But until such a solution appears, I
suggest we stick with the current solution. It works, and it is not all
that horrible. I hope that answers your question.
OK, that is fine. I just wanted to make sure it was researched to make
sure it has to be that way.

We have a large number of platforms supported, and if they can all be
put in the same file, great, but if there is some limitation on Alpha
Linux, we are stuck with that.

Have you tried defining it as an static or inline function in s_lock.h?
That should work, and keep it in the same file. Can you test that?

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Thu, 01 Jan 1998 21:40:44 -0500 (EST)
From: Carl Perry <caperry@mediaone.net>
Subject: Port status

PostgreSQL 6.2.1
RedHat 4.2, running Linux 2.0.32 on an i586 w/ 32MB SDRAM
Complied OKay, Installed OKay.
One failure on regression test:
copy_seq did not appear on the last set of rows.
As a result, the result file only had 65 instead of 66 rows.

Is this a cause for concern??


From scrappy
Date: 01-Jan-98
Time: 21:40:44

This message was sent by XFMail in Linux!
- ----------------------------------

From scrappy
Date: Thu, 1 Jan 1998 23:33:48 -0500
From: "Jethro Wright III" <jetman@li.net>
Subject: subscribe

subscribe
help
end

From scrappy
Date: Fri, 2 Jan 1998 00:17:57 -0500
From: "Jethro Wright III" <jetman@li.net>
Subject: Status of Win32 Port and Can I Help ?

Folks: Have been a user of mSQL from Hughes and while
it's a nice db server, I'd like something a little heavier
as alternative to Oracle's, MSOFT's, and Sybase's offerings,
hence I just pulled down PostGreSQL 6.21. I don't have a
Unix system, but I *do* have a nice Win95 development machine
w/ Visual C 5.0 and would like to get involved.

Regards....Jet

+=========================================================================+
+ I am Homer of Borg.... prepare to be assim... oooo... Donuts... +
+=========================================================================+

From scrappy
Date: Fri, 2 Jan 1998 01:44:04 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Status of Win32 Port and Can I Help ?
On Fri, 2 Jan 1998, Jethro Wright III wrote:


Folks: Have been a user of mSQL from Hughes and while
it's a nice db server, I'd like something a little heavier
as alternative to Oracle's, MSOFT's, and Sybase's offerings,
hence I just pulled down PostGreSQL 6.21. I don't have a
Unix system, but I *do* have a nice Win95 development machine
w/ Visual C 5.0 and would like to get involved.
I've been tempted to look into Cygnus' offerings as far as GCC and
all is concerned, which I *believe* supports the use of configure type
software...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Fri, 2 Jan 1998 12:25:42 -0600
From: Adam Fenn <Adam.Fenn@fennco.com>
Subject: pg95perl on alpha linux

I am trying to compile pg95perl.. As you can see in the second section
below, I am getting errors about int2.. Not really understanding what an
.xs file is completely I added a #include "postgres.h" line to Pg.xs..
That allowed it to compile. with a lot of warning.. . I see this
problem on both the alpha linux and on i386 linux, though I only need
the alpha to work. I did a make install, and then, I ran ./testlibpq.pl
. but I get more errors. Any help you can offer is appreciated..

Thanks!
Adam.

[root@brain pg95perl5-1.2.0]# ./testlibpq.pl
Can't find loadable object for module Pg in @INC
(/usr/lib/perl5/alpha-linux/5.0
0401 /usr/lib/perl5 /usr/lib/perl5/site_perl/alpha-linux
/usr/lib/perl5/site_per
l .) at ./testlibpq.pl line 15
BEGIN failed--compilation aborted at ./testlibpq.pl line 15.

cp Pg.pm ./blib/lib/Pg.pm
cp testlibpq.pl ./blib/lib/testlibpq.pl
/usr/bin/perl -I/usr/lib/perl5/alpha-linux/5.00401 -I/usr/lib/perl5
/usr/lib/per
l5/ExtUtils/xsubpp -typemap /usr/lib/perl5/ExtUtils/typemap -typemap
typemap Pg
.xs >Pg.tc && mv Pg.tc Pg.c
Please specify prototyping behavior for Pg.xs (see perlxs manual)
cc -c -I /usr/local/pgsql/include -Dbool=char -DHAS_BOOL
- -I/usr/local/include -O
2 -DVERSION=\"0.10\" -DXS_VERSION=\"0.10\" -fpic
- -I/usr/lib/perl5/alpha-linux
/5.00401/CORE Pg.c
Pg.xs: In function `XS_Pg_PQfsize':
Pg.xs:159: `int2' undeclared (first use this function)
Pg.xs:159: (Each undeclared identifier is reported only once
Pg.xs:159: for each function it appears in.)
Pg.xs:159: parse error before `RETVAL'
Pg.xs:160: `RETVAL' undeclared (first use this function)
Pg.xs: In function `XS_Pg_PQoidStatus':
Pg.xs:170: warning: assignment discards `const' from pointer target type
make: *** [Pg.o] Error 1

From scrappy
Date: Fri, 2 Jan 1998 17:09:39 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: postmaster dies with Bad system call (core dumped)

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


Your name : Bryan Mann
Your email address : bmann@whistle.com

Category : runtime: back-end
Severity : critical

Summary: postmaster dies with Bad system call (core dumped)

System Configuration
- --------------------
Operating System : FreeBSD2.2.x and FreeBSD3.0

PostgreSQL version : 6.1.2

Compiler used : gcc 2.7.2.1

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

FreeBSD stela 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Tue May 20 10:45:24 GMT 1997 jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC i386

FreeBSD chaco 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Thu Nov 13 11:02:24 PST 1997


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


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

Problem Description:
- --------------------
After installing postgres and doing initdb as pgsql
run postmaster -s.
It emits the error message on FreeBSD2.2.2
On FreeBSD it will "run" but on attempt to connect
with createdb it dies in the same manner with the
same error messages.
Repeated build/installs on different hardware with same
OS has the same behavior. Note that I did use the FreeBSD
port and the distribution from www.postgresql.org with
the same results.

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

Test Case:
- ----------
See problem description. To reproduce easily
in src/test/regress do:

gmake runtest

gdb shows the following

Program terminated with signal 12, Bad system call.
Cannot access memory at address 0x80d3080.
#0 0x815c481 in ?? ()
(gdb) bt
#0 0x815c481 in ?? ()
#1 0x8151c90 in ?? ()
#2 0x72644 in IpcSemaphoreKill ()
#3 0x7746e in ProcFreeAllSemaphores ()
#4 0x72466 in quasi_exitpg ()
#5 0x65e69 in CleanupProc ()
#6 0x65c3d in reaper ()
#7 <signal handler called>
#8 0x8192451 in ?? ()
#9 0x64d8e in PostmasterMain ()
#10 0x3bf82 in main ()
(gdb) q


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

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


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

From scrappy
Date: Fri, 2 Jan 1998 19:56:46 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Port Bug Report: postmaster dies with Bad system call (core dumped)
On Fri, 2 Jan 1998, Unprivileged user wrote:


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


Your name : Bryan Mann
Your email address : bmann@whistle.com

Category : runtime: back-end
Severity : critical

Summary: postmaster dies with Bad system call (core dumped)
Your kernel needs to be recompiled with the following:

options SYSVSHM
options SYSVSEM
options SYSVMSG



Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Fri, 2 Jan 1998 19:02:35 -0600
From: Adam Fenn <Adam.Fenn@fennco.com>
Subject: Alpha Linux and pg95perl

With the patch posted by Ryan Kirkpatrick a while ago, I was able to get
PosgreSQL compiled on my Alpha, running Linux.. From what I can tell in
my limited testing of the clients, it appears they work fine. My main
interest is to get pg95perl working, but I am having trouble getting to
test correctly.. What I mean is, that I run testlibpq.pl, from the
pg95perl5-1.2.0 distribution and it hangs inside the test_copy_in, and
test_copy_out routines on the lines that use PQendcopy. Everything
looks fine till that point. I am getting these results on both alpha
Linux and i386 Linux running RedHat 5.0 on each. I did have some
trouble getting pg95perl to compile correctly. I had to add an include
for postgres.h in Pg.xs. It gave me some warnings, but still compiled.
I realized this might not be the best place to post these questions, but
I thought someone might be able to shed some light on my situation, or
point me in the right direction.

Thanks!
Adam

From scrappy
Date: Fri, 2 Jan 1998 21:08:39 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Alpha Linux and pg95perl
With the patch posted by Ryan Kirkpatrick a while ago, I was able to get
PosgreSQL compiled on my Alpha, running Linux.. From what I can tell in
my limited testing of the clients, it appears they work fine. My main
interest is to get pg95perl working, but I am having trouble getting to
test correctly.. What I mean is, that I run testlibpq.pl, from the
pg95perl5-1.2.0 distribution and it hangs inside the test_copy_in, and
test_copy_out routines on the lines that use PQendcopy. Everything
looks fine till that point. I am getting these results on both alpha
Linux and i386 Linux running RedHat 5.0 on each. I did have some
trouble getting pg95perl to compile correctly. I had to add an include
for postgres.h in Pg.xs. It gave me some warnings, but still compiled.
I realized this might not be the best place to post these questions, but
I thought someone might be able to shed some light on my situation, or
point me in the right direction.
Postgres95 1.* used '.' to end a copy. PostgreSQL >= 6.* uses '\.'.
Someone needs to make sure the pg95perl package is updated. Please
inform the author.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Fri, 2 Jan 1998 23:09:27 -0600
From: Adam Fenn <Adam.Fenn@fennco.com>
Subject: RE: [PORTS] Alpha Linux and pg95perl

Thanks for the help.. I got it working.. It seems that the included test
program, "testlibpq.pl", was in fact sending, and looking for '\.'
instead of '.' .. Once I changed that in testlibpq.pl, everything works
great.. Thanks again Bruce!

Adam
-----Original Message-----
From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
Sent: Friday, January 02, 1998 9:09 PM
To: Adam Fenn
Cc: pgsql-ports@postgreSQL.org
Subject: Re: [PORTS] Alpha Linux and pg95perl
With the patch posted by Ryan Kirkpatrick a while ago, I was able to get
PosgreSQL compiled on my Alpha, running Linux.. From what I can tell in
my limited testing of the clients, it appears they work fine. My main
interest is to get pg95perl working, but I am having trouble getting to
test correctly.. What I mean is, that I run testlibpq.pl, from the
pg95perl5-1.2.0 distribution and it hangs inside the test_copy_in, and
test_copy_out routines on the lines that use PQendcopy. Everything
looks fine till that point. I am getting these results on both alpha
Linux and i386 Linux running RedHat 5.0 on each. I did have some
trouble getting pg95perl to compile correctly. I had to add an include
for postgres.h in Pg.xs. It gave me some warnings, but still compiled.
I realized this might not be the best place to post these questions, but
I thought someone might be able to shed some light on my situation, or
point me in the right direction.
Postgres95 1.* used '.' to end a copy. PostgreSQL >= 6.* uses '\.'.
Someone needs to make sure the pg95perl package is updated. Please
inform the author.

--
Bruce Momjian
maillist@candle.pha.pa.us
From scrappy
Date: Sat, 03 Jan 1998 09:31:41 +0100 (CET)
From: Andreas Beldowski <abel@on-luebeck.de>
Subject: postgres-6.2.1 error after Distribution update

This message is in MIME format
- --_=XFMail.1.2.p0.Linux:980103085633:3653=_
Content-Type: text/plain; charset=us-ascii

I have installed postgres-6.2.1 on my old system without any problems.
It worked as well with a patched AppGEN as an onlinedatabase
(see http://www.man.ac.uk/~whaley/ag/appgen.html). As http-server
i use apache-1.2.4. My hardware based on a gigabyte-586TX3 board with
a AMD K6-200MHz processor.

Than i have updated my german S.u.S.E.-Linux distribution form Version
5.0 to 5.1 (both with Linux-kernel 2.0.32).

First problem: every connect to postgres over the AppGEN-CGI-Scripts
brings an
Error: Cannot connect to PostgreSQL.
The owner of the http-process is made to a database user with
"createuser". With version 5.0 i was able to connect.

One change from 5.0 to 5.1 was the use of a shadow-password-system
(/etc/shadow) insted of the normal /etc/passwd.
Is this the cause of my problem? But why i'm able to connect to
the database with "psql"?

To solve this problems i try to compile postgres a second time. As an
attachment i send you the output of "./configure". A "make all" crashed
with:
gcc -o psql -L../../interfaces/libpq psql.o stringutils.o\
-lpq -ldl -lm -lbsd -lreadline -lhistory -export-dynamic\
-Wl,-rpath -Wl,/usr/local/pgsql/lib
/usr/lib/libreadline.a(display.o): In function `rl_redisplay':
display.o(.text+0x9bf): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `update_line':
display.o(.text+0xf26): undefined reference to `tputs'
...
My readline-lib is out of the package bash-2.01.1-4.
Did you have a solution to my problems?
- --
Gruss, Andreas Beldowski <abel@on-luebeck.de>
Luisenstr.70 Voice: 0451/3882240
D-23568 Luebeck http://www.on-luebeck.de/~abel/

- --_=XFMail.1.2.p0.Linux:980103085633:3653=_
Content-Disposition: attachment; filename="config.out"
Content-Transfer-Encoding: base64
Content-Description: config.out
Content-Type: application/octet-stream; name=config.out; SizeOnDisk=5505

Y3JlYXRpbmcgY2FjaGUgLi9jb25maWcuY2FjaGUKY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4u
LiBpNTg2LXBjLWxpbnV4LWdudQpjaGVja2luZyBlY2hvIHNldHRpbmcuLi4KKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKCVBvc3Ry
ZVNRTCB2Ni4yIEluc3RhbGxhdGlvbiBQcm9ncmFtCgpXZWxjb21lIHRvIHRoZSBuZXcgaW1wcm92
ZWQgUG9zdGdyZVNRTCBpbnN0YWxsYXRpb24gcHJvZ3JhbS4KVGhpcyBjb25maWd1cmF0aW9uIHBy
b2dyYW0gaXMgZm9yIHZlcnNpb24gNi4yIG9mIHRoZQpQb3N0Z3JlU1FMIHNvZnR3YXJlLgoKUGxl
YXNlIHNlbGVjdCBhIHRlbXBsYXRlIGZyb20gdGhlIG9uZXMgbGlzdGVkIGJlbG93LiAgSWYgbm8K
dGVtcGxhdGUgaXMgYXZhaWxhYmxlLCB0aGVuIHNlbGVjdCB0aGUgJ2dlbmVyaWMnIG9uZSBhbmQK
Y29uc2lkZXIgZW1haWxsaW5nIHNjcmFwcHlAaHViLm9yZyB3aXRoIHRoZSBhYm92ZSBsaW5lIHdo
aWNoCnN0YXJ0cyAnY2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZS4uLicKKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKYWl4LWNjCmFp
eC1nY2MKYWxwaGEKYnNkaS0yLjAKYnNkaS0yLjEKYnNkaS0zLjAKZGd1eApmcmVlYnNkCmdlbmVy
aWMKaHB1eC1jYwpocHV4LWdjYwppMzg2X3NvbGFyaXMtY2MKaTM4Nl9zb2xhcmlzLWdjYwppcml4
NQpsaW51eApsaW51eC1lbGYKbGludXhhbHBoYQpuZXRic2QKbmV4dHN0ZXAKc2NvCnNwYXJjX3Nv
bGFyaXMtY2MKc3BhcmNfc29sYXJpcy1nY2MKc3Vub3M0LWNjCnN1bm9zNC1nY2MKc3ZyNAp1bHRy
aXg0CnVuaXZlbAoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKgpBcHByb3ByaWF0ZSB0ZW1wbGF0ZSBmaWxlIHsgbGludXgtZWxmIH06
IAoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKgpXZSBub3cgbmVlZCB0byBrbm93IGlmIHlvdXIgY29tcGlsZXIgbmVlZHMgdG8gc2Vh
cmNoIGFueQplY2hvIGFkZGl0aW9uYWwgZGlyZWN0b3JpZXMgZm9yIGluY2x1ZGUgb3IgbGlicmFy
eSBmaWxlcy4gSWYKeW91IGRvbid0IGtub3cgdGhlIGFuc3dlcnMgdG8gdGhlc2UgcXVlc3Rpb25z
LCB0aGVuIGp1c3QKZWNobyBoaXQgZW50ZXIgYW5kIHdlIHdpbGwgdHJ5IGFuZCBmaWd1cmUgaXQg
b3V0LiBJZiB0aGluZ3MKZG9uJ3QgY29tcGlsZSBiZWNhdXNlIG9mIG1pc3NpbmcgbGlicmFyaWVz
IG9yIGluY2x1ZGUKZWNobyBmaWxlcywgdGhlbiB5b3UgcHJvYmFibHkgbmVlZCB0byBlbnRlciBz
b21ldGhpbmcgaGVyZS4KZW50ZXIgJ25vbmUnIG9yIG5ldyBkaXJlY3RvcmllcyB0byBvdmVycmlk
ZSBkZWZhdWx0CgpBZGRpdGlvbmFsIGRpcmVjdG9yaWVzIHRvIHNlYXJjaCBmb3IgaW5jbHVkZSBm
aWxlcyB7IC91c3IvaW5jbHVkZS9uY3Vyc2VzIC91c3IvaW5jbHVkZS9yZWFkbGluZSB9OiAtIHNl
dHRpbmcgQ1BQRkxBR1M9LUkvdXNyL2luY2x1ZGUvcmVhZGxpbmUKQWRkaXRpb25hbCBkaXJlY3Rv
cmllcyB0byBzZWFyY2ggZm9yIGxpYnJhcnkgZmlsZXMgeyAgfTogLSBzZXR0aW5nIExERkxBR1M9
CgotQVNTRVJUIENIRUNLSU5HIGRpc2FibGVkCmNoZWNraW5nIGZvciBnY2MuLi4gZ2NjCmNoZWNr
aW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgKGdjYyAtTzIgKSB3b3Jrcy4uLiB5ZXMKY2hlY2tp
bmcgd2hldGhlciB0aGUgQyBjb21waWxlciAoZ2NjIC1PMiApIGlzIGEgY3Jvc3MtY29tcGlsZXIu
Li4gbm8KY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgR05VIEMuLi4geWVzCmNoZWNraW5n
IHdoZXRoZXIgZ2NjIGFjY2VwdHMgLWcuLi4geWVzCmNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMg
cHJlcHJvY2Vzc29yLi4uIGdjYyAtRQpjaGVja2luZyBmb3IgZ2luc3RhbGwuLi4gbm8KY2hlY2tp
bmcgZm9yIGluc3RhbGxic2QuLi4gbm8KY2hlY2tpbmcgZm9yIGJzZGluc3QuLi4gbm8KY2hlY2tp
bmcgZm9yIHNjb2luc3QuLi4gbm8KY2hlY2tpbmcgZm9yIGluc3RhbGwuLi4gL3Vzci9iaW4vaW5z
dGFsbAotIFVzaW5nIC91c3IvYmluL2luc3RhbGwKY2hlY2tpbmcgZm9yIGZsZXguLi4gZmxleApj
aGVja2luZyBmb3IgeXl3cmFwIGluIC1sZmwuLi4geWVzCmNoZWNraW5nIHdoZXRoZXIgbG4gLXMg
d29ya3MuLi4geWVzCmNoZWNraW5nIHdoZXRoZXIgbWFrZSBzZXRzICR7TUFLRX0uLi4geWVzCmNo
ZWNraW5nIGZvciByYW5saWIuLi4gcmFubGliCmNoZWNraW5nIGZvciBmaW5kLi4uIC91c3IvYmlu
L2ZpbmQKY2hlY2tpbmcgZm9yIHRhci4uLiAvYmluL3RhcgpjaGVja2luZyBmb3Igc3BsaXQuLi4g
L3Vzci9iaW4vc3BsaXQKY2hlY2tpbmcgZm9yIGV0YWdzLi4uIG5vCmNoZWNraW5nIGZvciB4YXJn
cy4uLiAvdXNyL2Jpbi94YXJncwpjaGVja2luZyBmb3IgaXBjcy4uLiAvdXNyL2Jpbi9pcGNzCmNo
ZWNraW5nIGZvciBpcGNybS4uLiAvdXNyL2Jpbi9pcGNybQpjaGVja2luZyBmb3IgdHJic2QuLi4g
bm8KY2hlY2tpbmcgZm9yIHRyLi4uIC91c3IvYmluL3RyCmNoZWNraW5nIGZvciB5YWNjLi4uIC91
c3IvYmluL3lhY2MKY2hlY2tpbmcgZm9yIGJpc29uLi4uIC91c3IvYmluL2Jpc29uCi0gVXNpbmcg
L3Vzci9iaW4vYmlzb24gLXkgLWQKY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxjdXJzZXMuLi4gbm8K
Y2hlY2tpbmcgZm9yIG1haW4gaW4gLWx0ZXJtY2FwLi4uIG5vCmNoZWNraW5nIGZvciBtYWluIGlu
IC1saGlzdG9yeS4uLiB5ZXMKY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxyZWFkbGluZS4uLiB5ZXMK
Y2hlY2tpbmcgZm9yIHdyaXRlX2hpc3RvcnkgaW4gLWxyZWFkbGluZS4uLiB5ZXMKY2hlY2tpbmcg
Zm9yIG1haW4gaW4gLWxic2QuLi4geWVzCmNoZWNraW5nIGZvciBtYWluIGluIC1sbS4uLiB5ZXMK
Y2hlY2tpbmcgZm9yIG1haW4gaW4gLWxkbC4uLiB5ZXMKY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxz
b2NrZXQuLi4gbm8KY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxuc2wuLi4gbm8KY2hlY2tpbmcgZm9y
IG1haW4gaW4gLWxpcGMuLi4gbm8KY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxJUEMuLi4gbm8KY2hl
Y2tpbmcgZm9yIG1haW4gaW4gLWxsYy4uLiBubwpjaGVja2luZyBmb3IgbWFpbiBpbiAtbGRsZC4u
LiBubwpjaGVja2luZyBmb3IgbWFpbiBpbiAtbGxuLi4uIG5vCmNoZWNraW5nIGZvciBtYWluIGlu
IC1sbGQuLi4gbm8KY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxjb21wYXQuLi4gbm8KY2hlY2tpbmcg
Zm9yIG1haW4gaW4gLWxCU0QuLi4gbm8KY2hlY2tpbmcgZm9yIG1haW4gaW4gLWxjcnlwdC4uLiBu
bwpjaGVja2luZyBmb3IgbWFpbiBpbiAtbGdlbi4uLiBubwpjaGVja2luZyBmb3IgbWFpbiBpbiAt
bFBXLi4uIG5vCmNoZWNraW5nIGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzLi4uIHllcwpjaGVja2lu
ZyBmb3Igc3lzL3dhaXQuaCB0aGF0IGlzIFBPU0lYLjEgY29tcGF0aWJsZS4uLiB5ZXMKY2hlY2tp
bmcgZm9yIGxpbWl0cy5oLi4uIHllcwpjaGVja2luZyBmb3IgdW5pc3RkLmguLi4geWVzCmNoZWNr
aW5nIGZvciB0ZXJtaW9zLmguLi4geWVzCmNoZWNraW5nIGZvciB2YWx1ZXMuaC4uLiB5ZXMKY2hl
Y2tpbmcgZm9yIHN5cy9zZWxlY3QuaC4uLiBubwpjaGVja2luZyBmb3Igc3lzL3Jlc291cmNlLmgu
Li4geWVzCmNoZWNraW5nIGZvciBuZXRkYi5oLi4uIHllcwpjaGVja2luZyBmb3IgcmVhZGxpbmUu
aC4uLiB5ZXMKY2hlY2tpbmcgZm9yIGhpc3RvcnkuaC4uLiB5ZXMKY2hlY2tpbmcgZm9yIGRsZC5o
Li4uIG5vCmNoZWNraW5nIGZvciBjcnlwdC5oLi4uIG5vCmNoZWNraW5nIGZvciBlbmRpYW4uaC4u
LiB5ZXMKY2hlY2tpbmcgZm9yIGZsb2F0LmguLi4geWVzCmNoZWNraW5nIGZvciByZWFkbGluZS9o
aXN0b3J5LmguLi4geWVzCmNoZWNraW5nIGZvciB3b3JraW5nIGNvbnN0Li4uIHllcwpjaGVja2lu
ZyBmb3IgdWlkX3QgaW4gc3lzL3R5cGVzLmguLi4geWVzCmNoZWNraW5nIGZvciBpbmxpbmUuLi4g
aW5saW5lCmNoZWNraW5nIGZvciBtb2RlX3QuLi4geWVzCmNoZWNraW5nIGZvciBvZmZfdC4uLiB5
ZXMKY2hlY2tpbmcgZm9yIHNpemVfdC4uLiB5ZXMKY2hlY2tpbmcgd2hldGhlciB0aW1lLmggYW5k
IHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQuLi4geWVzCmNoZWNraW5nIHdoZXRoZXIg
c3RydWN0IHRtIGlzIGluIHN5cy90aW1lLmggb3IgdGltZS5oLi4uIHRpbWUuaApjaGVja2luZyBm
b3IgaW50IHRpbWV6b25lLi4uIHllcwpjaGVja2luZyBmb3IgdW5pb24gc2VtdW4uLi4geWVzCmNo
ZWNraW5nIHdoZXRoZXIgZ2NjIG5lZWRzIC10cmFkaXRpb25hbC4uLiBubwpjaGVja2luZyBmb3Ig
OC1iaXQgY2xlYW4gbWVtY21wLi4uIHllcwpjaGVja2luZyByZXR1cm4gdHlwZSBvZiBzaWduYWwg
aGFuZGxlcnMuLi4gdm9pZApjaGVja2luZyBmb3IgdnByaW50Zi4uLiB5ZXMKY2hlY2tpbmcgZm9y
IGlzaW5mLi4uIHllcwpjaGVja2luZyBmb3IgdHpzZXQuLi4geWVzCmNoZWNraW5nIGZvciBnZXRy
dXNhZ2UuLi4geWVzCmNoZWNraW5nIGZvciB2Zm9yay4uLiB5ZXMKY2hlY2tpbmcgZm9yIG1lbW1v
dmUuLi4geWVzCmNoZWNraW5nIGZvciBzaWdzZXRqbXAuLi4gbm8KY2hlY2tpbmcgZm9yIGtpbGwu
Li4geWVzCmNoZWNraW5nIGZvciBzeXNjb25mLi4uIHllcwpjaGVja2luZyBmb3Igc2lncHJvY21h
c2suLi4geWVzCmNoZWNraW5nIGZvciB3YWl0cGlkLi4uIHllcwpjaGVja2luZyBmb3Igc2V0c2lk
Li4uIHllcwpjaGVja2luZyBmb3IgcmFuZG9tLi4uIHllcwpjaGVja2luZyBmb3Igc3JhbmRvbS4u
LiB5ZXMKY2hlY2tpbmcgZm9yIGZjdnQuLi4geWVzCmNoZWNraW5nIGZvciBpbmV0X2F0b24uLi4g
eWVzCmNoZWNraW5nIGZvciBzdHJlcnJvci4uLiB5ZXMKY2hlY2tpbmcgZm9yIHN0cmR1cC4uLiB5
ZXMKY2hlY2tpbmcgZm9yIGNicnQuLi4geWVzCmNoZWNraW5nIGZvciByaW50Li4uIHllcwpjaGVj
a2luZyBzZXR0aW5nIFVTRV9MT0NBTEUuLi4gZGlzYWJsZWQKY2hlY2tpbmcgc2V0dGluZyBERUZf
UEdQT1JULi4uIDU0MzIKY2hlY2tpbmcgc2V0dGluZyBIQkEuLi4gZW5hYmxlZAp1cGRhdGluZyBj
YWNoZSAuL2NvbmZpZy5jYWNoZQpjcmVhdGluZyAuL2NvbmZpZy5zdGF0dXMKY3JlYXRpbmcgR05V
bWFrZWZpbGUKY3JlYXRpbmcgTWFrZWZpbGUuZ2xvYmFsCmNyZWF0aW5nIGJhY2tlbmQvcG9ydC9N
YWtlZmlsZQpjcmVhdGluZyBiaW4vcGdfdmVyc2lvbi9NYWtlZmlsZQpjcmVhdGluZyBiaW4vcHNx
bC9NYWtlZmlsZQpjcmVhdGluZyBiaW4vcGdfZHVtcC9NYWtlZmlsZQpjcmVhdGluZyBiYWNrZW5k
L3V0aWxzL0dlbl9mbWdydGFiLnNoCmNyZWF0aW5nIGluY2x1ZGUvY29uZmlnLmgKbGlua2luZyAu
L2luY2x1ZGUvcG9ydC9saW51eC5oIHRvIGluY2x1ZGUvb3MuaApsaW5raW5nIC4vbWFrZWZpbGVz
L01ha2VmaWxlLmxpbnV4IHRvIE1ha2VmaWxlLnBvcnQK
From scrappy
Date: Sat, 03 Jan 1998 19:23:40 -0500
From: Firstname LastName <gsam@praxis-sw.com>
Subject: (no subject)

subscribe

From scrappy
Date: Sun, 4 Jan 1998 23:57:34 -0500
From: darrenk@insightdist.com (Darren King)
Subject: (void)NULL in macros and aix

Four aix issues in the jan 04 snapshot. After doing the following, it compiled.
Getting late, so I'll test the install and regression data tomorrow.

1. "aix" wasn't defined, so necessary sections of code were missing.
Specifically in backend/utils/adt/float.c and backend/tcop/postgres.c.
Fixed by just removing since I was pretty sure what port I was building. :)

Scrappy, is this because of the porting work you were doing the last couple
of weeks?

How is this one to be resolved?

- ---------

2. This is more like a C issue rather than aix-specific. The aix compiler complains
about assigning the (void)NULL to isnull in the heap_getattr macro. Changing the
(void) to (bool) works and seems like it should be (bool) to match the type of isnull,
shouldn't it?

*** include/access/heapam.h.org Sun Jan 4 23:52:05 1998
- --- include/access/heapam.h Sun Jan 4 23:52:11 1998
***************
*** 101,110 ****
#define heap_getattr(tup, b, attnum, tupleDesc, isnull) \
(AssertMacro((tup) != NULL) ? \
((attnum) > (int) (tup)->t_natts) ? \
! (((isnull) ? (*(isnull) = true) : (void)NULL), (Datum)NULL) : \
((attnum) > 0) ? \
fastgetattr((tup), (attnum), (tupleDesc), (isnull)) : \
! (((isnull) ? (*(isnull) = false) : (void)NULL), heap_getsysattr((tup), (b), (attnum))) : \
(Datum)NULL)

extern HeapAccessStatistics heap_access_stats; /* in stats.c */
- --- 101,110 ----
#define heap_getattr(tup, b, attnum, tupleDesc, isnull) \
(AssertMacro((tup) != NULL) ? \
((attnum) > (int) (tup)->t_natts) ? \
! (((isnull) ? (*(isnull) = true) : (bool)NULL), (Datum)NULL) : \
((attnum) > 0) ? \
fastgetattr((tup), (attnum), (tupleDesc), (isnull)) : \
! (((isnull) ? (*(isnull) = false) : (bool)NULL), heap_getsysattr((tup), (b), (attnum))) : \
(Datum)NULL)

extern HeapAccessStatistics heap_access_stats; /* in stats.c */

- ---------

3. Is StrNCpy trying to be like the strncpy and return a pointer to (dst)?

I kept getting compiler errors with assigning the (void)s in it to (len > 0).

Checked the src for its usage and couldn't find anywhere using its' return value,
so I made this into...

#define StrNCpy(dst,src,len) do \
{ \
strncpy((dst),(src),(len)); \
if ((len) > 0) \
{ \
*((dst)+(len)-1)='\0'; \
} \
} while(0)

/*
((strncpy((dst),(src),(len)),(len > 0)) ? *((dst)+(len)-1)='\0' : ((void)NULL,(dst)))
*/

Any objections to submitting a patch for this change or should I try to rework the ?:
macro some more?

- ---------

4. Compiler complained about an empty file with the new alpha s_lock.c, so I applied the
following to give it a blank line to work with.

*** backend/storage/buffer/s_lock.c.org Sun Jan 4 23:39:09 1998
- --- backend/storage/buffer/s_lock.c Sun Jan 4 23:38:58 1998
***************
*** 62,65 ****
- --- 62,67 ----
} while (0);
}

+ #else
+ ;
#endif

- ---------

The pain in the aix guy...

darrenk

From scrappy
Date: Mon, 05 Jan 1998 01:44:58 -0500
From: "Billy G. Allie" <ballie01@mug.org>
Subject: UNIXware port (UW 2.1.2)

This is a multipart MIME message.

- --==_Exmh_-2683920510
Content-Type: text/plain; charset=us-ascii

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


Your name.........: Billy G. Allie
Your email address: Bill.Allie@mug.org


System Configuration
- ---------------------
Architecture......: Intel 486DX

Operating System..: UNIXware 2.1.2

PostgreSQL version: PostgreSQL-6.2.1

Compiler used.....: Optimizing C Compilation System (CCS) 3.0 09/26/96


Please enter a FULL description of your problem:
- ------------------------------------------------
The univel port is incomplete and fails in the following manner:

1. Configure does not properly recognize univel as a valid port.
2. Configure did not recognize the CC tag in the template file. (it also
does not recognize the ALL tag, but this is not fixed by the accompanying
patch).
3. The univel port does not have a working S_LOCK implementation (the S_LOCK
implementation used when NEED_I386_TAS_ASM is defined will work if gcc is
used to compile PostgreSQL).
4. The S_LOCK implementation used when NEED_I386_TAS_ASM will not work in a
multi-processor environment.
5. The version of lex supplied with UNIXware 2.1.2 will work.

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------
Configure and make PostgreSQL on UNIXware 2.1.2.

If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------
Problems 1, 2, 3, and 4 are fixed by the attached patch file.
Problem 5 can be fixed by using flex or using the scan.c file available on
the PostgreSQL web site.

NOTE: The patch file was made against PostgreSQL 6.2.1p7 source.


- --==_Exmh_-2683920510
Content-Type: text/plain ; name="v6.2.1_univel"; charset=us-ascii
Content-Description: v6.2.1_univel
Content-Disposition: attachment; filename="v6.2.1_univel"

*** src/backend/port/univel/Makefile.orig Sat Jan 3 05:57:39 1998
- --- src/backend/port/univel/Makefile Sat Jan 3 05:57:50 1998
***************
*** 16,22 ****

CFLAGS+=$(INCLUDE_OPT)

! OBJS = port.o #tas.o

all: SUBSYS.o

- --- 16,22 ----

CFLAGS+=$(INCLUDE_OPT)

! OBJS = port.o

all: SUBSYS.o

*** src/backend/port/univel/port.c.orig Thu Jan 1 02:37:26 1998
- --- src/backend/port/univel/port.c Fri Jan 2 03:53:51 1998
***************
*** 17,32 ****
#include "rusagestub.h"
#include "port-protos.h"

! long
! random()
{
! return (lrand48());
! }

! void
! srandom(int seed)
! {
! srand48((long int) seed);
}

int
- --- 17,29 ----
#include "rusagestub.h"
#include "port-protos.h"

! int
! my_isinf(double x)
{
! if (finite(x) || isnan(x))
! return 0;

! return 1;
}

int
***************
*** 67,170 ****
rusage->ru_utime.tv_usec = TICK_TO_USEC(u, tick_rate);
rusage->ru_stime.tv_sec = TICK_TO_SEC(s, tick_rate);
rusage->ru_stime.tv_usec = TICK_TO_USEC(u, tick_rate);
- - return (0);
- - }
- -
- - /*
- - * Copyright (c) 1987 Regents of the University of California.
- - * All rights reserved.
- - *
- - * Redistribution and use in source and binary forms are permitted
- - * provided that this notice is preserved and that due credit is given
- - * to the University of California at Berkeley. The name of the University
- - * may not be used to endorse or promote products derived from this
- - * software without specific written prior permission. This software
- - * is provided ``as is'' without express or implied warranty.
- - */
- -
- - #if defined(LIBC_SCCS) && !defined(lint)
- - static char sccsid[] = "@(#)strcasecmp.c 5.5 (Berkeley) 11/24/87";
- -
- - #endif /* LIBC_SCCS and not lint */
- -
- - #include <sys/types.h>
- - #include <string.h>
- -
- - /*
- - * This array is designed for mapping upper and lower case letter
- - * together for a case independent comparison. The mappings are
- - p * based upon ascii character sequences.
- - */
- - static unsigned char charmap[] = {
- - '\000', '\001', '\002', '\003', '\004', '\005', '\006', '\007',
- - '\010', '\011', '\012', '\013', '\014', '\015', '\016', '\017',
- - '\020', '\021', '\022', '\023', '\024', '\025', '\026', '\027',
- - '\030', '\031', '\032', '\033', '\034', '\035', '\036', '\037',
- - '\040', '\041', '\042', '\043', '\044', '\045', '\046', '\047',
- - '\050', '\051', '\052', '\053', '\054', '\055', '\056', '\057',
- - '\060', '\061', '\062', '\063', '\064', '\065', '\066', '\067',
- - '\070', '\071', '\072', '\073', '\074', '\075', '\076', '\077',
- - '\100', '\141', '\142', '\143', '\144', '\145', '\146', '\147',
- - '\150', '\151', '\152', '\153', '\154', '\155', '\156', '\157',
- - '\160', '\161', '\162', '\163', '\164', '\165', '\166', '\167',
- - '\170', '\171', '\172', '\133', '\134', '\135', '\136', '\137',
- - '\140', '\141', '\142', '\143', '\144', '\145', '\146', '\147',
- - '\150', '\151', '\152', '\153', '\154', '\155', '\156', '\157',
- - '\160', '\161', '\162', '\163', '\164', '\165', '\166', '\167',
- - '\170', '\171', '\172', '\173', '\174', '\175', '\176', '\177',
- - '\200', '\201', '\202', '\203', '\204', '\205', '\206', '\207',
- - '\210', '\211', '\212', '\213', '\214', '\215', '\216', '\217',
- - '\220', '\221', '\222', '\223', '\224', '\225', '\226', '\227',
- - '\230', '\231', '\232', '\233', '\234', '\235', '\236', '\237',
- - '\240', '\241', '\242', '\243', '\244', '\245', '\246', '\247',
- - '\250', '\251', '\252', '\253', '\254', '\255', '\256', '\257',
- - '\260', '\261', '\262', '\263', '\264', '\265', '\266', '\267',
- - '\270', '\271', '\272', '\273', '\274', '\275', '\276', '\277',
- - '\300', '\341', '\342', '\343', '\344', '\345', '\346', '\347',
- - '\350', '\351', '\352', '\353', '\354', '\355', '\356', '\357',
- - '\360', '\361', '\362', '\363', '\364', '\365', '\366', '\367',
- - '\370', '\371', '\372', '\333', '\334', '\335', '\336', '\337',
- - '\340', '\341', '\342', '\343', '\344', '\345', '\346', '\347',
- - '\350', '\351', '\352', '\353', '\354', '\355', '\356', '\357',
- - '\360', '\361', '\362', '\363', '\364', '\365', '\366', '\367',
- - '\370', '\371', '\372', '\373', '\374', '\375', '\376', '\377',
- - };
- -
- - int
- - strcasecmp(char *s1, char *s2)
- - {
- - register unsigned char u1,
- - u2;
- -
- - for (;;)
- - {
- - u1 = (unsigned char) *s1++;
- - u2 = (unsigned char) *s2++;
- - if (charmap[u1] != charmap[u2])
- - {
- - return charmap[u1] - charmap[u2];
- - }
- - if (u1 == '\0')
- - {
- - return 0;
- - }
- - }
- - }
- -
- - #include <sys/utsname.h>
- -
- - int
- - gethostname(char *name, int namelen)
- - {
- - static struct utsname mname;
- - static int called = 0;
- -
- - if (!called)
- - {
- - called++;
- - uname(&mname);
- - }
- - strncpy(name, mname.nodename, (SYS_NMLN < namelen ? SYS_NMLN : namelen));
- -
return (0);
}
- --- 64,68 ----
*** src/backend/port/univel/frontend-port-protos.h.orig Thu Jan 1 02:44:21 1998
- --- src/backend/port/univel/frontend-port-protos.h Thu Jan 1 03:57:33 1998
***************
*** 1,12 ****
/*-------------------------------------------------------------------------
*
! * port-protos.h--
! * port-specific prototypes for Intel x86/Intel SVR4
*
*
* Copyright (c) 1994, Regents of the University of California
*
! * port-protos.h,v 1.2 1995/03/17 06:40:18 andrew Exp
*
*-------------------------------------------------------------------------
*/
- --- 1,12 ----
/*-------------------------------------------------------------------------
*
! * frontend-port-protos.h--
! * frontend-port-specific prototypes for Intel x86/Intel SVR4
*
*
* Copyright (c) 1994, Regents of the University of California
*
! * frontend-port-protos.h,v 1.2 1995/03/17 06:40:18 andrew Exp
*
*-------------------------------------------------------------------------
*/
***************
*** 14,22 ****
#define FPORT_PROTOS_H

/* port.c */
- - extern long random(void);
- - extern void srandom(int seed);
- - extern int strcasecmp(char *s1, char *s2);
- - extern int gethostname(char *name, int namelen);

#endif /* FPORT_PROTOS_H */
- --- 14,18 ----
*** src/backend/port/univel/port-protos.h.orig Thu Jan 1 02:44:38 1998
- --- src/backend/port/univel/port-protos.h Thu Jan 1 03:57:46 1998
***************
*** 32,40 ****
#define pg_dlerror dlerror

/* port.c */
- - extern long random(void);
- - extern void srandom(int seed);
- - extern int strcasecmp(char *s1, char *s2);
- - extern int gethostname(char *name, int namelen);

#endif /* PORT_PROTOS_H */
- --- 32,36 ----
*** src/include/port/univel.h.orig Thu Jan 1 03:39:24 1998
- --- src/include/port/univel.h Fri Jan 2 02:16:11 1998
***************
*** 2,18 ****
#define NO_EMPTY_STMTS
#define USE_POSIX_SIGNALS
#define SYSV_DIRENT
- -
- - #if 0
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
- -
- - #endif
- -
- - extern long random(void);
- - extern void srandom(int seed);
- - extern int strcasecmp(char *s1, char *s2);
- - extern int gethostname(char *name, int namelen);

#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
- --- 2,11 ----
#define NO_EMPTY_STMTS
#define USE_POSIX_SIGNALS
#define SYSV_DIRENT
#define HAS_TEST_AND_SET
+ #define NEED_I386_TAS_ASM
+ #define USE_UNIVEL_CC_ASM
typedef unsigned char slock_t;

#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
*** src/include/storage/s_lock.h.orig Thu Jan 1 18:37:52 1998
- --- src/include/storage/s_lock.h Fri Jan 2 02:12:06 1998
***************
*** 93,99 ****
/*
* OSF/1 (Alpha AXP)
*
! * Note that slock_t on the Alpha AXP is msemaphore instead of char
* (see storage/ipc.h).
*/

- --- 93,99 ----
/*
* OSF/1 (Alpha AXP)
*
! * Note that slock_t on the Alpha AXP is semaphore instead of char
* (see storage/ipc.h).
*/

***************
*** 295,309 ****

#if defined(NEED_I386_TAS_ASM)

#define S_LOCK(lock) do \
{ \
slock_t _res; \
do \
{ \
! __asm__("xchgb %0,%1": "=q"(_res), "=m"(*lock):"0"(0x1)); \
} while (_res != 0); \
} while (0)
!
#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)
- --- 295,325 ----

#if defined(NEED_I386_TAS_ASM)

+ #if defined(USE_UNIVEL_CC_ASM)
+ asm void S_LOCK(char *lval)
+ {
+ % lab again;
+ /* Upon entry, %eax will contain the pointer to the lock byte */
+ pushl %ebx
+ xchgl %eax,%ebx
+ movb $-1,%al
+ again:
+ lock
+ xchgb %al,(%ebx)
+ cmpb $0,%al
+ jne again
+ popl %ebx
+ }
+ #else
#define S_LOCK(lock) do \
{ \
slock_t _res; \
do \
{ \
! __asm__("lock xchgb %0,%1": "=q"(_res), "=m"(*lock):"0"(0x1)); \
} while (_res != 0); \
} while (0)
! #endif
#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)
*** src/interfaces/libpgtcl/Makefile.orig Sat Jan 3 05:05:24 1998
- --- src/interfaces/libpgtcl/Makefile Sat Jan 3 05:30:16 1998
***************
*** 30,48 ****

ifeq ($(PORTNAME), linux)
ifdef LINUX_ELF
- - ifeq ($(CC), gcc)
- - CFLAGS += -fpic -fPIC
- - endif
shlib := libpgtcl.so.1
install-shlib-dep := install-shlib
LDFLAGS += -L $(SRCDIR)/interfaces/libpq -lpq
endif
endif

ifeq ($(PORTNAME), i386_solaris)
! CFLAGS+= -fPIC
endif

OBJS= pgtcl.o pgtclCmds.o pgtclId.o


- --- 30,67 ----

ifeq ($(PORTNAME), linux)
ifdef LINUX_ELF
shlib := libpgtcl.so.1
install-shlib-dep := install-shlib
LDFLAGS += -L $(SRCDIR)/interfaces/libpq -lpq
+ LDFLAGS_SL := -shared
+ CFLAGS += $(CFLAGS_SL)
endif
endif

+ ifeq ($(PORTNAME), BSD44_derived)
+ shlib := libpq.so.1.0
+ install-shlib-dep := install-shlib
+ LDFLAGS += -L $(SRCDIR)/interfaces/libpq -lpq
+ LDFLAGS_SL := -x -Bshareable -Bforcearchive
+ CFLAGS += $(CFLAGS_SL)
+ endif
+
ifeq ($(PORTNAME), i386_solaris)
! shlib := libpq.so.1
! install-shlib-dep := install-shlib
! LDFLAGS += -L $(SRCDIR)/interfaces/libpq -lpq
! LDFLAGS_SL := -G -z text
! CFLAGS += $(CFLAGS_SL)
endif

+ ifeq ($(PORTNAME), univel)
+ shlib := libpgtcl.so.1
+ install-shlib-dep := install-shlib
+ LDFLAGS += -L $(SRCDIR)/interfaces/libpq -lpq
+ LDFLAGS_SL := -G -z text
+ CFLAGS += $(CFLAGS_SL)
+ endif
+
OBJS= pgtcl.o pgtclCmds.o pgtclId.o


***************
*** 57,63 ****
$(RANLIB) libpgtcl.a

libpgtcl.so.1: $(OBJS)
! $(CC) $(LDFLAGS) -shared $(OBJS) -o libpgtcl.so.1
rm -f libpgtcl.so
ln -s libpgtcl.so.1 libpgtcl.so

- --- 76,82 ----
$(RANLIB) libpgtcl.a

libpgtcl.so.1: $(OBJS)
! $(CC) $(LDFLAGS) $(LDFLAGS_SL) $(OBJS) -o libpgtcl.so.1
rm -f libpgtcl.so
ln -s libpgtcl.so.1 libpgtcl.so

*** src/interfaces/libpq/Makefile.orig Sat Jan 3 04:47:11 1998
- --- src/interfaces/libpq/Makefile Sat Jan 3 04:49:10 1998
***************
*** 49,54 ****
- --- 49,60 ----
LDFLAGS_SL = -G -z text
CFLAGS += $(CFLAGS_SL)
endif
+ ifeq ($(PORTNAME), univel)
+ install-shlib-dep := install-shlib
+ shlib := libpq.so.1
+ LDFLAGS_SL = -G -z text
+ CFLAGS += $(CFLAGS_SL)
+ endif

all: libpq.a $(shlib) c.h

*** src/makefiles/Makefile.univel.orig Thu Jan 1 03:00:35 1998
- --- src/makefiles/Makefile.univel Fri Jan 2 03:41:09 1998
***************
*** 1,9 ****
! #
! # The univel port is almost guaranteed NOT to work yet.
! #
! # MAKE_EXPORTS is required for svr4 loaders that want a file of
! # symbol names to tell them what to export/import.
! #MAKE_EXPORTS= true

%.so: %.o
$(LD) -G -Bdynamic -o $@ $<
- --- 1,4 ----
! LDFLAGS+= -lc89 -Wl,-Bexport

%.so: %.o
$(LD) -G -Bdynamic -o $@ $<
*** src/template/univel.orig Fri Jan 2 21:01:38 1998
- --- src/template/univel Sat Jan 3 01:52:33 1998
***************
*** 1,10 ****
AROPT:crs
! CFLAGS:-I$(SRCDIR)/backend/port/univel
! SHARED_LIB:-fPIC
! ALL:-DHAVE_RUSAGE -m486 -Dsvr4
SRCH_INC:
SRCH_LIB:
USE_LOCALE:no
DLSUFFIX:.so
YFLAGS:-d
! YACC:bison -y
- --- 1,11 ----
AROPT:crs
! CFLAGS:-I$(SRCDIR)/backend/port/univel -Xa -v -DHAVE_RUSAGE -O -K i486,host,inline,loop_unroll -Dsvr4
! SHARED_LIB:-K PIC
! ALL:
SRCH_INC:
SRCH_LIB:
USE_LOCALE:no
DLSUFFIX:.so
YFLAGS:-d
! YACC:yacc
! CC:cc

This increases the number of typedef's understood by BSD indent from 100
to 1000.

*** ./lexi.c.orig Mon Sep 8 17:55:47 1997
- --- ./lexi.c Mon Sep 8 17:02:10 1997
***************
*** 58,64 ****
int rwcode;
};

! struct templ specials[100] =
{
"switch", 1,
"case", 2,
- --- 58,64 ----
int rwcode;
};

! struct templ specials[1000] =
{
"switch", 1,
"case", 2,
*** src/configure.orig Wed Dec 31 20:20:56 1997
- --- src/configure Sat Jan 3 01:26:24 1998
***************
*** 585,596 ****
hpux*) PORTNAME='hpux';;
osf*) PORTNAME='alpha';;
sco*) PORTNAME='sco';;
- - sysv4*) PORTNAME='svr4';;
sysv4.2*)
case "$host_vendor" in
univel) PORTNAME='univel';;
*) PORTNAME='unknown';;
esac ;;
*) echo ""
echo "*************************************************************"
echo "configure does not currently recognize your operating system,"
- --- 585,596 ----
hpux*) PORTNAME='hpux';;
osf*) PORTNAME='alpha';;
sco*) PORTNAME='sco';;
sysv4.2*)
case "$host_vendor" in
univel) PORTNAME='univel';;
*) PORTNAME='unknown';;
esac ;;
+ sysv4*) PORTNAME='svr4';;
*) echo ""
echo "*************************************************************"
echo "configure does not currently recognize your operating system,"
***************
*** 669,685 ****
export TEMPLATE
echo ""

! AROPT=`grep AROPT $TEMPLATE | awk -F: '{print $2}'`
! SHARED_LIB=`grep SHARED_LIB $TEMPLATE | awk -F: '{print $2}'`
! CFLAGS=`grep CFLAGS $TEMPLATE | awk -F: '{print $2}'`
! SRCH_INC=`grep SRCH_INC $TEMPLATE | awk -F: '{print $2}'`
! SRCH_LIB=`grep SRCH_LIB $TEMPLATE | awk -F: '{print $2}'`
! USE_LOCALE=`grep USE_LOCALE $TEMPLATE | awk -F: '{print $2}'`
! DLSUFFIX=`grep DLSUFFIX $TEMPLATE | awk -F: '{print $2}'`
! DL_LIB=`grep DL_LIB $TEMPLATE | awk -F: '{print $2}'`
! YACC=`grep YACC $TEMPLATE | awk -F: '{print $2}'`
! YFLAGS=`grep YFLAGS $TEMPLATE | awk -F: '{print $2}'`
!

echo "**************************************************************"
echo "We now need to know if your compiler needs to search any
- --- 669,685 ----
export TEMPLATE
echo ""

! AROPT=`grep "^AROPT:" $TEMPLATE | awk -F: '{print $2}'`
! SHARED_LIB=`grep "^SHARED_LIB:" $TEMPLATE | awk -F: '{print $2}'`
! CFLAGS=`grep "^CFLAGS:" $TEMPLATE | awk -F: '{print $2}'`
! SRCH_INC=`grep "^SRCH_INC:" $TEMPLATE | awk -F: '{print $2}'`
! SRCH_LIB=`grep "^SRCH_LIB:" $TEMPLATE | awk -F: '{print $2}'`
! USE_LOCALE=`grep "^USE_LOCALE:" $TEMPLATE | awk -F: '{print $2}'`
! DLSUFFIX=`grep "^DLSUFFIX:" $TEMPLATE | awk -F: '{print $2}'`
! DL_LIB=`grep "^DL_LIB:" $TEMPLATE | awk -F: '{print $2}'`
! YACC=`grep "^YACC:" $TEMPLATE | awk -F: '{print $2}'`
! YFLAGS=`grep "^YFLAGS:" $TEMPLATE | awk -F: '{print $2}'`
! CC=`grep "^CC:" $TEMPLATE | awk -F: '{print $2}'`

echo "**************************************************************"
echo "We now need to know if your compiler needs to search any
*** src/configure.in.orig Wed Dec 31 20:22:00 1997
- --- src/configure.in Sat Jan 3 01:46:33 1998
***************
*** 21,32 ****
hpux*) PORTNAME='hpux';;
osf*) PORTNAME='alpha';;
sco*) PORTNAME='sco';;
- - sysv4*) PORTNAME='svr4';;
sysv4.2*)
case "$host_vendor" in
univel) PORTNAME='univel';;
*) PORTNAME='unknown';;
esac ;;
*) echo ""
echo "*************************************************************"
echo "configure does not currently recognize your operating system,"
- --- 21,32 ----
hpux*) PORTNAME='hpux';;
osf*) PORTNAME='alpha';;
sco*) PORTNAME='sco';;
sysv4.2*)
case "$host_vendor" in
univel) PORTNAME='univel';;
*) PORTNAME='unknown';;
esac ;;
+ sysv4*) PORTNAME='svr4';;
*) echo ""
echo "*************************************************************"
echo "configure does not currently recognize your operating system,"
***************
*** 107,123 ****
export TEMPLATE
echo ""

! AROPT=`grep AROPT $TEMPLATE | awk -F: '{print $2}'`
! SHARED_LIB=`grep SHARED_LIB $TEMPLATE | awk -F: '{print $2}'`
! CFLAGS=`grep CFLAGS $TEMPLATE | awk -F: '{print $2}'`
! SRCH_INC=`grep SRCH_INC $TEMPLATE | awk -F: '{print $2}'`
! SRCH_LIB=`grep SRCH_LIB $TEMPLATE | awk -F: '{print $2}'`
! USE_LOCALE=`grep USE_LOCALE $TEMPLATE | awk -F: '{print $2}'`
! DLSUFFIX=`grep DLSUFFIX $TEMPLATE | awk -F: '{print $2}'`
! DL_LIB=`grep DL_LIB $TEMPLATE | awk -F: '{print $2}'`
! YACC=`grep YACC $TEMPLATE | awk -F: '{print $2}'`
! YFLAGS=`grep YFLAGS $TEMPLATE | awk -F: '{print $2}'`
!

dnl We now need to check for additional directories (include
dnl and library directories.
- --- 107,123 ----
export TEMPLATE
echo ""

! AROPT=`grep "^AROPT:" $TEMPLATE | awk -F: '{print $2}'`
! SHARED_LIB=`grep "^SHARED_LIB:" $TEMPLATE | awk -F: '{print $2}'`
! CFLAGS=`grep "^CFLAGS:" $TEMPLATE | awk -F: '{print $2}'`
! SRCH_INC=`grep "^SRCH_INC:" $TEMPLATE | awk -F: '{print $2}'`
! SRCH_LIB=`grep "^SRCH_LIB:" $TEMPLATE | awk -F: '{print $2}'`
! USE_LOCALE=`grep "^USE_LOCALE:" $TEMPLATE | awk -F: '{print $2}'`
! DLSUFFIX=`grep "^DLSUFFIX:" $TEMPLATE | awk -F: '{print $2}'`
! DL_LIB=`grep "^DL_LIB:" $TEMPLATE | awk -F: '{print $2}'`
! YACC=`grep "^YACC:" $TEMPLATE | awk -F: '{print $2}'`
! YFLAGS=`grep "^YFLAGS:" $TEMPLATE | awk -F: '{print $2}'`
! CC=`grep "^CC:" $TEMPLATE | awk -F: '{print $2}'`

dnl We now need to check for additional directories (include
dnl and library directories.

- --==_Exmh_-2683920510
Content-Type: text/plain; charset=us-ascii

____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
/| | 7436 Hartwell | Compuserve: 76337,2061
-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
/ |LLIE | (313) 582-1540 |
- --==_Exmh_-2683920510--

From scrappy
Date: Mon, 5 Jan 1998 08:19:09 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] (void)NULL in macros and aix

Four aix issues in the jan 04 snapshot. After doing the following, it compiled.
Getting late, so I'll test the install and regression data tomorrow.

1. "aix" wasn't defined, so necessary sections of code were missing.
Specifically in backend/utils/adt/float.c and backend/tcop/postgres.c.
Fixed by just removing since I was pretty sure what port I was building. :)

Scrappy, is this because of the porting work you were doing the last couple
of weeks?

How is this one to be resolved? Marc?
---------

2. This is more like a C issue rather than aix-specific. The aix compiler complains
about assigning the (void)NULL to isnull in the heap_getattr macro. Changing the
(void) to (bool) works and seems like it should be (bool) to match the type of isnull,
shouldn't it?

*** include/access/heapam.h.org Sun Jan 4 23:52:05 1998
--- include/access/heapam.h Sun Jan 4 23:52:11 1998
***************
*** 101,110 ****
#define heap_getattr(tup, b, attnum, tupleDesc, isnull) \
(AssertMacro((tup) != NULL) ? \
((attnum) > (int) (tup)->t_natts) ? \
! (((isnull) ? (*(isnull) = true) : (void)NULL), (Datum)NULL) : \
((attnum) > 0) ? \
fastgetattr((tup), (attnum), (tupleDesc), (isnull)) : \
! (((isnull) ? (*(isnull) = false) : (void)NULL), heap_getsysattr((tup), (b), (attnum))) : \
(Datum)NULL)

extern HeapAccessStatistics heap_access_stats; /* in stats.c */
--- 101,110 ----
#define heap_getattr(tup, b, attnum, tupleDesc, isnull) \
(AssertMacro((tup) != NULL) ? \
((attnum) > (int) (tup)->t_natts) ? \
! (((isnull) ? (*(isnull) = true) : (bool)NULL), (Datum)NULL) : \
((attnum) > 0) ? \
fastgetattr((tup), (attnum), (tupleDesc), (isnull)) : \
! (((isnull) ? (*(isnull) = false) : (bool)NULL), heap_getsysattr((tup), (b), (attnum))) : \
(Datum)NULL)

extern HeapAccessStatistics heap_access_stats; /* in stats.c */
We made if void so that we would stop getting gcc warnings about 'unused
left-hand side of conditional' messages. Does aix complain or stop. If
it just complains, I think we have to leave it alone, because everyone
else will complain about bool.
---------

3. Is StrNCpy trying to be like the strncpy and return a pointer to (dst)?

I kept getting compiler errors with assigning the (void)s in it to (len > 0).

Checked the src for its usage and couldn't find anywhere using its' return value,
so I made this into...

#define StrNCpy(dst,src,len) do \
{ \
strncpy((dst),(src),(len)); \
if ((len) > 0) \
{ \
*((dst)+(len)-1)='\0'; \
} \
} while(0)

/*
((strncpy((dst),(src),(len)),(len > 0)) ? *((dst)+(len)-1)='\0' : ((void)NULL,(dst)))
*/

Any objections to submitting a patch for this change or should I try to rework the ?:
macro some more?
Yes, it is supposed to be strncpy with a forced NULL. Why not return
the value to be consistent? Why doesn't your compiler complain about
functoin calls whose values are returned but not used? Because this is
a macro, I guess. I think we have to leave it alone.
---------

4. Compiler complained about an empty file with the new alpha s_lock.c, so I applied the
following to give it a blank line to work with.

*** backend/storage/buffer/s_lock.c.org Sun Jan 4 23:39:09 1998
--- backend/storage/buffer/s_lock.c Sun Jan 4 23:38:58 1998
***************
*** 62,65 ****
--- 62,67 ----
} while (0);
}

+ #else
+ ;
#endif

---------

The pain in the aix guy...
This one sounds OK, but I have the alpha guy testing another fix that
will eventually remove this file.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Mon, 05 Jan 1998 18:54:54 -0600
From: Jose Alberto Patino Limon <alpatino@banamex.com>
Subject: Postgress installation in HP-UX 10.20.

Hi everybody:
I have the following information for you.
I installed Postgress 6.2.1 in the next platform:
Apollo 9000 Serie 800 with PA-RISC running HP-UX 10.20
- - The version of PostgreSQL (v6.2.1, 6.1.1, beta 970703, etc.).
v6.2.1
- - Your operating system (i.e. RedHat v4.0 Linux v2.0.26).
HP-UX 10.20
- - Your hardware (SPARC, i486, etc.).
Precision Arquitecture-RISC (32 o 64 Mz ???)
- - Install problems:
I had problems running HP's make so I need to install 'gmake'. By the
way, I couldn't find a program called gmake so I got 'make' instead.
I did ftp from prep.ai.mit.edu. File:/pub/gnu/make-3.76.1.tar.gz

I hadn't any problems to install gnu make.

As to the Postgress installation I had the following problems:
When I ran 'make all', I got a yacc error:
Too many states compiling gram.y. (I got a clue from the yacc compiler:
use Ns option)
Solution: I edited the Makefile.global file. I modified the line with
the YFLAGS variable (line 211), so I added the option Ns with a value of
5000(The default for HP was 1000)
After this change The problem vanished but I found the next problem:The
size of look ahead tables was not big enough. (Default 650) So I
modified to 2500 with the Nl (En -el) option.
At last the line was modified in the following way:
Original line:
YFLAGS= -d
Modified line
YFLAGS= -d -Ns5000 -Nl2500

After this I got the next fatal error:
cc -I../../include -W l,-E -Ae -DNOFIXADE -Dhpux -I.. -I.
include -c scan.c -o scan.o
cc: "scan.c", line 145: error 1000: Unexpected symbol: "&".

The problem was very simple to solve. One comment was erronous written.
The '/' was missing. I just edited the file scan.c and everythig worked
fine.

I ran the regress test and I could find some tests failed principally
due to the floating point precision.

From scrappy
Date: Mon, 05 Jan 1998 20:18:29 -0500
From: "Billy G. Allie" <ballie01@mug.org>
Subject: Re: [PORTS] UNIXware port (UW 2.1.2)

There was an error in my previous post. The following line:

5. The version of lex supplied with UNIXware 2.1.2 will work.

should read:

5. The version of lex supplied with UNIXware 2.1.2 will not work.
- --
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
/| | 7436 Hartwell | Compuserve: 76337,2061
-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
/ |LLIE | (313) 582-1540 |
From scrappy
Date: Tue, 06 Jan 1998 03:25:47 +0100
From: Palle Girgensohn <girgen@partitur.se>
Subject: pgaccess (libpgtcl) on Solaris?

Hi!

I've tried pretty hard now to get the libpgtcl.so library to work
together with PgAccess (http://www.flex.ro/pgaccess/), but to no avail.
I'm using it on FreeBSD w/ no problems, but am having trouble linking(?)
libpgtcl.so on Solaris. I *think* I have done the necessary changes to
the Makefiles.

I read about the problem in the postgres mail archive from end October
1997, but didn't see anyone having a solution. Do have any tips?

Thanks in advance!

I'm using Solaris 2.5.1, Tcl 8.0p2, Tk 8.0p2, Postgres 6.2.1 and
pgaccess 0.73.

Here's what happens:
pgaccess
Error in startup script: couldn't load file
"/opt/pgsql/lib/libpgtcl.so": ld.so.1: /usr/local/bin/wish8.0: fatal:
relocation error: symbol not found: pgresStatus: referenced in
/opt/pgsql/lib/libpgtcl.so
while executing
"load /opt/pgsql/lib/libpgtcl.so"
(procedure "main" line 3)
invoked from within
"main $argc $argv"
(file "/usr/local/bin/pgaccess" line 3235)


The compilation of postgres' libpgtcl looks like this:

...
gmake -C libpgtcl all
gmake[2]: Entering directory
`/usr/share/src/postgresql-6.2.1/src/interfaces/libpgtcl
'
gcc -I../../include -I/usr/local/include
- -I../../backend/port/sparc_solaris -Wall -W
missing-prototypes -Dsparc_solaris -I../../backend -I../../include
- -I../../interfaces
/libpq -I/usr/local/include -fpic -fPIC -c pgtcl.c -o pgtcl.o
gcc -I../../include -I/usr/local/include
- -I../../backend/port/sparc_solaris -Wall -W
missing-prototypes -Dsparc_solaris -I../../backend -I../../include
- -I../../interfaces
/libpq -I/usr/local/include -fpic -fPIC -c pgtclCmds.c -o pgtclCmds.o
gcc -I../../include -I/usr/local/include
- -I../../backend/port/sparc_solaris -Wall -W
missing-prototypes -Dsparc_solaris -I../../backend -I../../include
- -I../../interfaces
/libpq -I/usr/local/include -fpic -fPIC -c pgtclId.c -o pgtclId.o
ar crs libpgtcl.a `lorder pgtcl.o pgtclCmds.o pgtclId.o | tsort`
ranlib libpgtcl.a
gcc -L/usr/local/lib -L/usr/local/lib/tcl8.0 -lgen -lcrypt -lnsl
- -lsocket -ldl -lm -l
readline -ltermcap -lcurses -L ../../interfaces/libpq -lpq -shared
pgtcl.o pgtclCmds
.o pgtclId.o -o libpgtcl.so.1.0
rm -f libpgtcl.so
ln -s libpgtcl.so.1.0 libpgtcl.so
gmake[2]: Leaving directory
`/usr/share/src/postgresql-6.2.1/src/interfaces/libpgtcl'
...

and the gmake install of ditto:

...
gmake -C libpgtcl install
gmake[2]: Entering directory
`/usr/share/src/postgresql-6.2.1/src/interfaces/libpgtcl
'
/usr/ucb/installbsd -c -m 444 libpgtcl.h /opt/pgsql/include/libpgtcl.h
/usr/ucb/installbsd -c -m 664 libpgtcl.a /opt/pgsql/lib/libpgtcl.a
/usr/ucb/installbsd -c -m 664 libpgtcl.so.1.0 \
/opt/pgsql/lib/libpgtcl.so.1.0
rm -f /opt/pgsql/lib/libpgtcl.so
ln -s libpgtcl.so.1 /opt/pgsql/lib/libpgtcl.so
gmake[2]: Leaving directory
`/usr/share/src/postgresql-6.2.1/src/interfaces/libpgtcl'
...

From scrappy
Date: Tue, 6 Jan 1998 10:38:24 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Compile fatally dies

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


Your name : Mark Greatrix
Your email address : mgreatri@anasazi.com

Category : install: compile
Severity : critical

Summary: Compile fatally dies

System Configuration
- --------------------
Operating System : Linux 2.0.27 ELF Slackware

PostgreSQL version : 6.2.1

Compiler used : gcc version 2.7.2

Hardware:
- ---------
Compaq ProSignia (486 DX2 66)
48M RAM
Linux ukcomm9 2.0.27 #2 Thu Jan 9 16:44:20 CST 1997 i486



Versions of other tools:
- ------------------------
GNU Make version 3.74
flex version 2.5.4a



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

Problem Description:
- --------------------
After ./configure & make all
eventually dies with....
make[2]: Entering directory `/usr/src/pgsql/postgresql-6.2.1/src/backend/bootstrap'
d bootparse.y
make[2]: d: Command not found



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

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



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

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



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

From scrappy
Date: Tue, 6 Jan 1998 18:07:02 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: i can't find the keywords in the sql.l man-page

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


Your name : Bernhard Klingbeil
Your email address : bernhard.klingbeil@hamburg.netsurf.de

Category : unknown
Severity : non-critical

Summary: i can't find the keywords in the sql.l man-page

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

PostgreSQL version : 6.2.1

Compiler used :

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


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


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

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


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

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


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

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


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

From scrappy
Date: Tue, 6 Jan 1998 19:51:03 -0700 (MST)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Subject: Re: [PORTS] Alpha Linux and pg95perl
On Fri, 2 Jan 1998, Adam Fenn wrote:

With the patch posted by Ryan Kirkpatrick a while ago, I was able to get
PosgreSQL compiled on my Alpha, running Linux.. From what I can tell in
my limited testing of the clients, it appears they work fine. My main
My patch should have only fixed one of the problems plaguing pgsql
and Linux/Alpha. With that patch, pgsql should now successfully compile on
Linux/Alpha. But it will not run correctly, as during the run of initdb a
core dump (seg fault) is still occuring and stopping things dead in ones
tracks. If this did not happen to you on Linux/Alpha, I would love to know
just exactly what you did. No one else has managed to get past initdb
(with current versions of pgsql).

- ----------------------------------------------------------------------------
"For to me to live is Christ, and to die is gain." |
--- Philippians 1:21 (KJV) |
- ----------------------------------------------------------------------------
Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
- ----------------------------------------------------------------------------
http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
- ----------------------------------------------------------------------------

From scrappy
Date: Tue, 6 Jan 1998 19:51:20 -0700 (MST)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Subject: Re: [PORTS] Test and Set fixed for Linux/Alpha!
On Thu, 1 Jan 1998, The Hermit Hacker wrote:

You can't access the CVS repository remotely (unless you have login access
to the server)...except using CVSup...see ftp.postgresql.org:/pub/CVSup for
more details
Ah... I thought CVSup was a shortened verion of getting things by
CVS, a slang. But it is really a program! Ok, thanks for helping me out! I
will snag a current version of pgsql in the next couple of days, compile
it, and make sure my patch made it in to the tree in one piece. I will
report my results. Thanks.

- ----------------------------------------------------------------------------
"For to me to live is Christ, and to die is gain." |
--- Philippians 1:21 (KJV) |
- ----------------------------------------------------------------------------
Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
- ----------------------------------------------------------------------------
http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
- ----------------------------------------------------------------------------

From scrappy
Date: Tue, 6 Jan 1998 19:51:31 -0700 (MST)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Subject: Re: [PORTS] Test and Set fixed for Linux/Alpha!
On Thu, 1 Jan 1998, Bruce Momjian wrote:

OK, that is fine. I just wanted to make sure it was researched to make
sure it has to be that way.
That is fine.
We have a large number of platforms supported, and if they can all be
put in the same file, great, but if there is some limitation on Alpha
Linux, we are stuck with that.

Have you tried defining it as an static or inline function in s_lock.h?
That should work, and keep it in the same file. Can you test that?
Yes, I have tried both. A static function resulted in multiple
defintions when multiple object files were linked together into a binary
or library. If one.c and two.c both called S_LOCK, then linking one.o and
two.o into all.o resulted in gcc throughing a multiple definition error
and giving up. The inline function resulted the same as the macro did,
multiple definition of labels in the assembly code. So both alternatives
suggested have been tried and failed. Hope this answers you question.

- ----------------------------------------------------------------------------
"For to me to live is Christ, and to die is gain." |
--- Philippians 1:21 (KJV) |
- ----------------------------------------------------------------------------
Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
- ----------------------------------------------------------------------------
http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
- ----------------------------------------------------------------------------

From scrappy
Date: 07 Jan 1998 16:16:31 -0500
From: "Roland B. Roberts" <roberts@panix.com>
Subject: Re: [PORTS] Test and Set fixed for Linux/Alpha!
"Ryan" == Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
Ryan> Yes, I have tried both. A static function resulted in

Do you mean this as in (1) you tried both separately, or (2) you tried
them both together?

I don't have access to an Alpha, but on other architectures, I have
successfully used static inline together to keep a function from
appearing anyplace except in the particular module. Perhap gcc has a
problem on the Alpha?

roland
- --
Roland B. Roberts, PhD Custom Software Solutions
roberts@panix.com 101 West 15th St #4NN
New York, NY 10011

From scrappy
Date: Thu, 8 Jan 1998 04:41:18 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report:

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


Your name :
Your email address :

Category :
Severity :

Summary:

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

PostgreSQL version :

Compiler used :

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


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


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

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


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

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


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

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


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

From scrappy
Date: Sat, 10 Jan 1998 00:14:22 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Port Bug Report: "cluster" after "update"("insert") make a problem

Fixed in 6.3. Beta testing February 1.
Summary: "cluster" after "update"("insert") make a problem

System Configuration
--------------------
Operating System : FreeBSD 2.2.2

PostgreSQL version : 6.1

Compiler used : gcc 2.7.2.1

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

Versions of other tools:
------------------------
gmake 3.75, flex 2.5.4

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

Problem Description:
--------------------
Unless "vacuum" after "update" or "insert", the command
"cluster" do not work correctly: 1) Table not clustered,
2) backend create "temp_*", 3) backend close connection

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

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

create table table1 (i int...; insert into table1 ...;
create index i_i on table1 using btree (i);
cluster i_i on table1; update table1...;
cluster i_i on table1; <-- BUG

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

Solution:
---------


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


- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Fri, 9 Jan 1998 23:25:17 -0600
From: Adam Fenn <Adam.Fenn@fennco.com>
Subject: the 'money' type

Where can I find some documentation on how to use the money data type in
pgsql?

Thanks!
Adam

From scrappy
Date: Sat, 10 Jan 1998 09:07:06 -0500 (EST)
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [PORTS] the 'money' type

Thus spake Adam Fenn
Where can I find some documentation on how to use the money data type in
pgsql?
I never did get around to that. The code has some explanations. There
isn't really much. You create a type as money and you can assign values
such as '$123,456.78' (dollar sign optional) to it and it displays it
in the same format. You can do the usual comparisons on money types
as well as My Dear Aunt Sally with itself and some reasonable other
types such as int2, int4 and float. There is also a function in the
code to output money amounts in words ("One hundred fifty four dollars
and sixty five cents" for example) but I don't know if this is used
anywhere. I guess it's available for using as a function. I think
something like the following has to be added to the ibki file.

insert OID = xxx (cash_words_out PGUID 11 f t f 1 f 23 "0" 100 0 0 100 foo ba)

Then you would be able to do this.

darcy=> alter table xtest add column m money;
ADD
darcy=> update xtest set m = '123,456.78';
UPDATE 1
darcy=> select * from xtest;
d |m
- -----------+-----------
Jan 07 1998|$123,456.78
(1 row)

darcy=> select cash_words_out(m) from xtest;

At this point it would have printed the amount in words.

- --
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

From scrappy
Date: Sat, 10 Jan 1998 18:08:43 -0600
From: Adam Fenn <Adam.Fenn@fennco.com>
Subject: WARN: Bad money external representation 72.22

I have am having a very hard time using the money type. I am running a
stock RedHat 5.0 system with PostgreSQL 6.2.1 .. Here is an example of
what I am doing:

testdb=> create table test (price money);
CREATE
testdb=> insert into test values ('75.40');
WARN: Bad money external representation 75.40
testdb=> insert into test values (75.40);
WARN: Bad money external representation 75.400000
testdb=> insert into test values ($75.40);
WARN: parser: parse error at or near "40"
testdb=> insert into test values ('$75.40');
WARN: Bad money external representation $75.40
testdb=> insert into test values ($7540);
WARN: Parameter '$7540' is out of range
testdb=> and on and on and on...

Does any one else have the same problem? Am I doing something wrong? Is
this a bug?

Thanks!
Adam

From scrappy
Date: Sun, 11 Jan 1998 03:42:21 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Subject: Re: [PORTS] WARN: Bad money external representation 72.22
I have am having a very hard time using the money type. I am running a
stock RedHat 5.0 system with PostgreSQL 6.2.1

Does any one else have the same problem? Am I doing something wrong? Is
this a bug?
postgres=> create table test (price money);
CREATE
postgres=> insert into test values ('75.40');
INSERT 18131 1
postgres=> insert into test values (75.40);
INSERT 18132 1
postgres=> select * from test;
price
- ------
$75.40
$75.40
(2 rows)

The money type does change behavior if the USE_LOCALE compiler definition
is set. If it is, then it calls localeconv() to determine the correct
parameters for an acceptable input. Could that be your trouble?

- Tom

From scrappy
Date: Sun, 11 Jan 1998 17:01:10 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] (void)NULL in macros and aix

Four aix issues in the jan 04 snapshot. After doing the following, it compiled.
Getting late, so I'll test the install and regression data tomorrow.

1. "aix" wasn't defined, so necessary sections of code were missing.
Specifically in backend/utils/adt/float.c and backend/tcop/postgres.c.
Fixed by just removing since I was pretty sure what port I was building. :)

Scrappy, is this because of the porting work you were doing the last couple
of weeks?

How is this one to be resolved?

---------

2. This is more like a C issue rather than aix-specific. The aix compiler complains
about assigning the (void)NULL to isnull in the heap_getattr macro. Changing the
(void) to (bool) works and seems like it should be (bool) to match the type of isnull,
shouldn't it?

*** include/access/heapam.h.org Sun Jan 4 23:52:05 1998
--- include/access/heapam.h Sun Jan 4 23:52:11 1998
***************
*** 101,110 ****
#define heap_getattr(tup, b, attnum, tupleDesc, isnull) \
(AssertMacro((tup) != NULL) ? \
((attnum) > (int) (tup)->t_natts) ? \
! (((isnull) ? (*(isnull) = true) : (void)NULL), (Datum)NULL) : \
((attnum) > 0) ? \
fastgetattr((tup), (attnum), (tupleDesc), (isnull)) : \
! (((isnull) ? (*(isnull) = false) : (void)NULL), heap_getsysattr((tup), (b), (attnum))) : \
(Datum)NULL)

extern HeapAccessStatistics heap_access_stats; /* in stats.c */
--- 101,110 ----
#define heap_getattr(tup, b, attnum, tupleDesc, isnull) \
(AssertMacro((tup) != NULL) ? \
((attnum) > (int) (tup)->t_natts) ? \
! (((isnull) ? (*(isnull) = true) : (bool)NULL), (Datum)NULL) : \
((attnum) > 0) ? \
fastgetattr((tup), (attnum), (tupleDesc), (isnull)) : \
! (((isnull) ? (*(isnull) = false) : (bool)NULL), heap_getsysattr((tup), (b), (attnum))) : \
(Datum)NULL)

extern HeapAccessStatistics heap_access_stats; /* in stats.c */
Looks like we may need a port-specific macro to define the return type
for this macro.
---------

3. Is StrNCpy trying to be like the strncpy and return a pointer to (dst)?

I kept getting compiler errors with assigning the (void)s in it to (len > 0).

Checked the src for its usage and couldn't find anywhere using its' return value,
so I made this into...

#define StrNCpy(dst,src,len) do \
{ \
strncpy((dst),(src),(len)); \
if ((len) > 0) \
{ \
*((dst)+(len)-1)='\0'; \
} \
} while(0)

/*
((strncpy((dst),(src),(len)),(len > 0)) ? *((dst)+(len)-1)='\0' : ((void)NULL,(dst)))
*/

Any objections to submitting a patch for this change or should I try to rework the ?:
macro some more?
Same.



- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Tue, 13 Jan 1998 08:48:28 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: regression.{port} files

Under src/test/regress, there are files called:

regression.{freebsd,sparc_solaris}

These represent the difference between "expected" and "results" that
resulted from the regression tests on those platforms. I'm currently
working on i386_solaris as well, and hope to have that up later this
afternoon.

If anyone wants to add similar for their particular platform, please
upload a gzip'd copy to ftp.postgresql.org/pub/incoming and let me know.

The idea is two fold. It gives those doing the regression tests a basis
of what is "acceptable deviation" from the tests and it gives the
developers a chance to see how the various platforms/ports fare

Since we are still developing this release, don't consider this to be any
more then a debugging tool..."acceptable deviation" only applies on a
release :)

From scrappy
Date: Tue, 13 Jan 1998 22:22:16 -0600 (CST)
From: Systems Whizzard <lindahl@caesar.org>
Subject: PostgreSQL running on our system

Hello:

You stated that you wished users to EMAIL their installation
experiences with POSTGRESQL.

Herewith are my particulars

POSTGRESQL version : 6.2.1
Our OS : Solaris 2.5.1
Hardware : Sparc Netra i150
Regression test results : Some errors, none unusual that I could tell

A note: the hardest part of the install/compile was getting the
compilation environment correct. GMAKE was easy ... GCC was NOT 'cuz
we took the "standard" installation for SOLARIS 2.5.1 when we
initially built the machine.

Problem is that the "default" does NOT include some of the standard
utilities (LEX, in specific) and it does NOT include the standard libc
libraries.

I had to scramble around to make sure these were installed.

A side note: as of the date of this EMAIL, "glibc" (the GNU version of
libc) does NOT compile/install correctly on SOLARIS 2.5.x. I wrote to
the GNU folks and they said that no one has done the port successfully
yet.

We look forward to using POSTGRESQL in our research (medical
terminology/semantics database). Many thanks to the POSTGRESQL team for their
hard work.

Charlie
============================================================================
"There is now recognition that most of | Charlie Lindahl
the work currently conducted in | lindahl@uta.edu
business is left-brain activity. | CAESAR lab/EE Department
Visualization will prove crucial to | University of Texas at Arlington
engaging the creative right-brain.." | http://testor.uta.edu/~lindahl
- Mike Graves, former SGI CIO |
- ----------------------------------------------------------------------------
Disclaimer: #include <std/disclaimer.h>

From scrappy
Date: Thu, 15 Jan 1998 02:53:45 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: CHANGE to be used as COLUMN name

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


Your name : Reiner Kappenberger
Your email address : Reiner.Kappenberger@dachau.baynet.de

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

Summary: CHANGE to be used as COLUMN name

System Configuration
- --------------------
Operating System : Solaris 2.6

PostgreSQL version : 6.2.1

Compiler used : gcc-2.7.2.3

Hardware:
- ---------
Sparc IPX, 64MB

Versions of other tools:
- ------------------------
Complete GNU toolset (gcc, make, ld, etc).

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

Problem Description:
- --------------------
For a running project it is required that the name CHANGE
be used as a column of TIMESTAMP. Is there any chance to
get a fix for this? CHANGE is to be used as a stamp that
indicates the last time the values have been modified.
The customer is running the system already on another
database (RDB).

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

Test Case:
- ----------
Just create a table with CHANGE.

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

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


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

From scrappy
Date: Thu, 15 Jan 1998 03:06:19 -0500 (EST)
From: Fernando Durango <fernando@ns.nyc.datacom.net>
Subject: Compile problems

Just thought you guys would like to know about this, and maybe
have a solution. I am on an i586 machine, running NetBSD 1.3
(New release from the NetBSD people) and am tryinto to compile the
snapshot that was available from your main FTP on 01/14/98

I seem to get most of the way through the compile, when I get this:
gcc -I../../include -I/usr/local/include -O2 -pipe -Wall
- -Wmissing-prototypes -I.. -Wno-error -c scan.c -o scan.o
lex.yy.c:800: warning: no previous prototype for `yylex'
scan.l: In function `yylex':
scan.l:202: `ABORT' undeclared (first use this function)
scan.l:202: (Each undeclared identifier is reported only once
scan.l:202: for each function it appears in.)
scan.l: At top level:
scan.l:379: warning: no previous prototype for `yyerror'
scan.l: In function `yyerror':
scan.l:380: `ABORT' undeclared (first use this function)
lex.yy.c: At top level:
lex.yy.c:2103: warning: `yy_flex_realloc' defined but not used
gmake[2]: *** [scan.o] Error 1
gmake[2]: Leaving directory `/usr/src/pgsql/src/backend/parser'
gmake[1]: *** [parser.dir] Error 2
gmake[1]: Leaving directory `/usr/src/pgsql/src/backend'
gmake: *** [all] Error 2

This is a stock NetBSD 1.3 system. Please let me know if I am sending
this to the wrong place, or you know of a better place to get a solution
to this, let me know. Thanks for all the work that you have put into
postgres.

-Fernando

From scrappy
Date: Thu, 15 Jan 1998 13:21:32 +0100
From: webmaster@unicaen.fr
Subject: to unsubscribe

Hello,

I'd like to strike my name off this list of subscribers. Who can help me?=


Thanks.


The webmaster of the University of Caen.

From scrappy
Date: Thu, 15 Jan 1998 08:02:41 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Compile problems

Just remove src/backend/parser/scan.c and run make again. You just need
to regenerate scan.c on your system and you should be fine

On Thu, 15 Jan 1998, Fernando Durango wrote:

Just thought you guys would like to know about this, and maybe
have a solution. I am on an i586 machine, running NetBSD 1.3
(New release from the NetBSD people) and am tryinto to compile the
snapshot that was available from your main FTP on 01/14/98

I seem to get most of the way through the compile, when I get this:
gcc -I../../include -I/usr/local/include -O2 -pipe -Wall
-Wmissing-prototypes -I.. -Wno-error -c scan.c -o scan.o
lex.yy.c:800: warning: no previous prototype for `yylex'
scan.l: In function `yylex':
scan.l:202: `ABORT' undeclared (first use this function)
scan.l:202: (Each undeclared identifier is reported only once
scan.l:202: for each function it appears in.)
scan.l: At top level:
scan.l:379: warning: no previous prototype for `yyerror'
scan.l: In function `yyerror':
scan.l:380: `ABORT' undeclared (first use this function)
lex.yy.c: At top level:
lex.yy.c:2103: warning: `yy_flex_realloc' defined but not used
gmake[2]: *** [scan.o] Error 1
gmake[2]: Leaving directory `/usr/src/pgsql/src/backend/parser'
gmake[1]: *** [parser.dir] Error 2
gmake[1]: Leaving directory `/usr/src/pgsql/src/backend'
gmake: *** [all] Error 2

This is a stock NetBSD 1.3 system. Please let me know if I am sending
this to the wrong place, or you know of a better place to get a solution
to this, let me know. Thanks for all the work that you have put into
postgres.

-Fernando


From scrappy
Date: Thu, 15 Jan 1998 14:10:08 +0100 (MET)
From: Postgres-Verwalter <postgres@mfo.de>
Subject: BSD-Only function in source-file

If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to pgsql-ports@postgresql.org.

To report any other bug, fill out the form below and e-mail it to
pgsql-bugs@postgresql.org.

If you not only found the problem but solved it and generated a patch
then e-mail it to pgsql-patches@postgresql.org instead. Please use the
command "diff -c" to generate the patch.

You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.

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


Your name : Helmut Biesenbach
Your email address : helmut@mfo.de


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

Operating System (example: Linux 2.0.26 ELF) : Solaris 2.4

PostgreSQL version (example: PostgreSQL-6.2.1): PostgreSQL-6.2.1

Compiler used (example: gcc 2.7.2) : cc 3.0.1


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

The source-file src/bin/pg_passwd/pg_passwd.c has a reference to
a bsd-only include file "strings.h" and a library routine "index()"



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





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

On System V, the include file "strings.h" is not needed, it's counterpart
"string.h" was already included. The name of the corresponding function
to the bsd-"index()" is "strchr()" on System V. I suggest an #ifdef
to solve this in the future.

From scrappy
Date: Thu, 15 Jan 1998 09:51:51 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] BSD-Only function in source-file
The source-file src/bin/pg_passwd/pg_passwd.c has a reference to
a bsd-only include file "strings.h" and a library routine "index()"



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





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

On System V, the include file "strings.h" is not needed, it's counterpart
"string.h" was already included. The name of the corresponding function
to the bsd-"index()" is "strchr()" on System V. I suggest an #ifdef
to solve this in the future.
This fix is in the next release.
- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Thu, 15 Jan 1998 09:47:56 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Compile problems

Try 6.2.1. I think the snapshot is not working properly at this time.


Just thought you guys would like to know about this, and maybe
have a solution. I am on an i586 machine, running NetBSD 1.3
(New release from the NetBSD people) and am tryinto to compile the
snapshot that was available from your main FTP on 01/14/98

I seem to get most of the way through the compile, when I get this:
gcc -I../../include -I/usr/local/include -O2 -pipe -Wall
-Wmissing-prototypes -I.. -Wno-error -c scan.c -o scan.o
lex.yy.c:800: warning: no previous prototype for `yylex'
scan.l: In function `yylex':
scan.l:202: `ABORT' undeclared (first use this function)
scan.l:202: (Each undeclared identifier is reported only once
scan.l:202: for each function it appears in.)
scan.l: At top level:
scan.l:379: warning: no previous prototype for `yyerror'
scan.l: In function `yyerror':
scan.l:380: `ABORT' undeclared (first use this function)
lex.yy.c: At top level:
lex.yy.c:2103: warning: `yy_flex_realloc' defined but not used
gmake[2]: *** [scan.o] Error 1
gmake[2]: Leaving directory `/usr/src/pgsql/src/backend/parser'
gmake[1]: *** [parser.dir] Error 2
gmake[1]: Leaving directory `/usr/src/pgsql/src/backend'
gmake: *** [all] Error 2

This is a stock NetBSD 1.3 system. Please let me know if I am sending
this to the wrong place, or you know of a better place to get a solution
to this, let me know. Thanks for all the work that you have put into
postgres.

-Fernando




- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Thu, 15 Jan 1998 10:27:12 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Compile problems
On Thu, 15 Jan 1998, Bruce Momjian wrote:

Try 6.2.1. I think the snapshot is not working properly at this time.
Huh?

From scrappy
Date: Thu, 15 Jan 1998 15:50:15 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Subject: Re: [PORTS] Port Bug Report: CHANGE to be used as COLUMN name
Summary: CHANGE to be used as COLUMN name
PostgreSQL version : 6.2.1
Problem Description:
--------------------
For a running project it is required that the name CHANGE
be used as a column of TIMESTAMP. Is there any chance to
get a fix for this? CHANGE is to be used as a stamp that
indicates the last time the values have been modified.
The customer is running the system already on another
database (RDB).

--------------------
It looks like CHANGE is orphaned or was never used.

Edit src/backend/parser/{gram.y,keywords.c} and remove the instance of the
string CHANGE in gram.y and the line containing CHANGE in keywords.c.

Then, do a "make clean install" and things should work. Sometimes I do a new
initdb, but that shouldn't be necessary.

We'll fix this for v6.3, unless someone had a planned use for the keyword
(which is unlikely).

- Tom

From scrappy
Date: Thu, 15 Jan 1998 12:01:40 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Compile problems
On Thu, 15 Jan 1998, Bruce Momjian wrote:

Try 6.2.1. I think the snapshot is not working properly at this time.
Huh?
OK, remove scan.c and recompile.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Thu, 15 Jan 1998 13:14:44 -0500 (EST)
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [PORTS] to unsubscribe

Thus spake webmaster@unicaen.fr (with text buried in a MIME message)
Hello,

I'd like to strike my name off this list of subscribers. Who can help me?=


Thanks.


The webmaster of the University of Caen.
Classic. Just classic.

- --
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

From scrappy
Date: Thu, 15 Jan 1998 16:15:30 -0500 (EST)
From: Fernando Durango <fernando@ns.nyc.datacom.net>
Subject: Re: [PORTS] Compile problems
On Thu, 15 Jan 1998, Bruce Momjian wrote:
Try 6.2.1. I think the snapshot is not working properly at this time.
Huh?
OK, remove scan.c and recompile.
Hey, that worked like a charm. I am trying to add all the system
definitions to my uid pgsql, do I need to add these to all my
user .cshrc/.login files if I want them to be able to use the databases?
set PATH=$PATH:/usr/local/pgsql/bin
set MANPATH=$MANPATH:/usr/local/pgsql/man
set PGLIB=/usr/local/pgsql/lib
set PGDATA=/usr/local/pgsql/data

Also, how can I password protect databases?
Can I set up permissions like user a can select and view, but only users b
and c can update and insert?

-F

From scrappy
Date: Fri, 16 Jan 1998 17:48:27 +0900
From: Youki Kadobayashi <youki@center.osaka-u.ac.jp>
Subject: postgres 6.2.1 success

Hi,

I compiled, installed and tested postgresql 6.2.1 on the following
platforms. Thank you all for useful software.

version OS hardware regression test
6.2.1 BSD/OS 3.0 ThinkPad 760 successful
6.2.1 Solaris 2.5 Sun Ultra 1 successful

I reviewed some tests that said "failed"; they were actually
minor differences in error messages (mostly differences in
textual representation of errno ERANGE) and minor differences
in numeric precision.

BTW, I had performance problem with many INSERTs when using
postgres from DBD::Pg perl5 module. That problem can be solved
by turning off AutoCommit feature like this:

$dbh->{AutoCommit} = 0;

This single statement turned out to improve bulk INSERT
performance by 24 times.

I hope this problem be covered in FAQ.

Thanks again for great software...

Youki Kadobayashi, Osaka University

From scrappy
Date: Fri, 16 Jan 1998 16:26:04 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;

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


Your name : Arkadiy Vavilin
Your email address : ar@bizlink.ru

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

Summary: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;

System Configuration
- --------------------
Operating System : Linux-ELF(RH4.1), Solaris-2.5.1

PostgreSQL version : 6.2.1+patch1,2,3,4,5,6,7

Compiler used :

Hardware:
- ---------
Pentium-120, 32M

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


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

Problem Description:
- --------------------
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
This SQL works fine on postgres-6.1 and give me not right answer on Postgresql-6.2.1 + Patch 1..7
on two platforms - Linux(RH4.1) and Solaris 2.5.1
The sample table is here http://www.bizlink.ru/test/logtmp.dmp.gz
The result not groupped. Result should have about 89 rows, but it have 14410 rows on Linux

On Solaris it gives 89 rows (right) on the screen and
if I add "INTO TABLE qq" - gives me 93 rows


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

Test Case:
- ----------
http://www.bizlink.ru/test/logtmp.dmp.gz - load it to table logtmp
and run SQL:
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
then see qq-table

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

Solution:
- ---------
Do not know

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

From scrappy
Date: Fri, 16 Jan 1998 16:33:29 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;

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


Your name : Arkadiy Vavilin
Your email address : ar@bizlink.ru

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

Summary: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;

System Configuration
- --------------------
Operating System : Linux-ELF(RH4.1), Solaris-2.5.1

PostgreSQL version : 6.2.1+patch1,2,3,4,5,6,7

Compiler used :

Hardware:
- ---------
Pentium-120, 32M; SUN ULTRA 2

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


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

Problem Description:
- --------------------
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
This SQL works fine on postgres-6.1 and give me not right answer on Postgresql-6.2.1 + Patch 1..7
on two platforms - Linux(RH4.1) and Solaris 2.5.1
The sample table is here http://www.bizlink.ru/test/logtmp.dmp.gz
The result not groupped. Result should have about 89 rows, but it have 14410 rows on Linux

On Solaris it gives 89 rows (right) on the screen and
if I add "INTO TABLE qq" - gives me 93 rows


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

Test Case:
- ----------
http://www.bizlink.ru/test/logtmp.dmp.gz - load it to table logtmp
and run SQL:
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
then see qq-table
This bug have place if the table is big enouth (30000-60000 rows)
If You do (...WHERE cmd='go') and result will be small, it's works fine.



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

Solution:
- ---------
Do not know

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

From scrappy
Date: Sat, 17 Jan 1998 02:50:43 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Subject: Re: [PORTS] Port Bug Report: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
This SQL works fine on postgres-6.1 and give me not right answer on Postgresql-6.2.1 + Patch 1..7
on two platforms - Linux(RH4.1) and Solaris 2.5.1
The sample table is here http://www.bizlink.ru/test/logtmp.dmp.gz
The result not groupped. Result should have about 89 rows, but it have 14410 rows on Linux

On Solaris it gives 89 rows (right) on the screen and
if I add "INTO TABLE qq" - gives me 93 rows
I believe this is the same problem at least a couple of us have reported under Linux. Unfortunately,
the problem is apparently not reproducible on all systems, and other developers do not see it. So,
difficult for them to believe, and harder to debug :)

- Tom

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

Test Case:
----------
http://www.bizlink.ru/test/logtmp.dmp.gz - load it to table logtmp
and run SQL:
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
then see qq-table
From scrappy
Date: Sat, 17 Jan 1998 17:43:18 +0200
From: Cyril VELTER <cyril@micronet.fr>
Subject: BeOS Port

Hi,


I'm in the process of evaluate a BeOS (http://www.be.com) port.
After hacking a bit in templates and port files, I've manage to configure
the package (I don't think that everything is OK). When I try to "make
all", I get errors on some files :

A lot of symbols are not defined : F_BOOLIN, F_BOOLOUT, F_CHARIN, F_CHAROUT ...
scankey.c : fmgr_info : cannot convert long* to int*
...

I'm not realy used to makefiles (I use IDE) so some tip about
creating a good template and port specific files would be usefull.


thanks

PS : I use a metrowerks complier (mwcc).


Cyril

- ------------------------------------------------------------
cyril@micronet.fr cyril.velter@edfgdf.fr
http://www.micronet.fr/~cyril

From scrappy
Date: Sat, 17 Jan 1998 16:27:42 -0500
From: darrenk@insightdist.com (Darren King)
Subject: Re: [PORTS] Port Bug Report: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
This SQL works fine on postgres-6.1 and give me not right answer on Postgresql-6.2.1 + Patch 1..7
on two platforms - Linux(RH4.1) and Solaris 2.5.1
The sample table is here http://www.bizlink.ru/test/logtmp.dmp.gz
The result not groupped. Result should have about 89 rows, but it have 14410 rows on Linux

On Solaris it gives 89 rows (right) on the screen and
if I add "INTO TABLE qq" - gives me 93 rows
I believe this is the same problem at least a couple of us have reported under Linux. Unfortunately,
the problem is apparently not reproducible on all systems, and other developers do not see it. So,
difficult for them to believe, and harder to debug :)
I tried to reproduce on aix here and could not. I tried to get the above
test data, only I couldn't un-gzip it without errors.

But...with the following...

\connect username
create table t1 (c1 char(8), c2 char(8));
copy t1 from stdin;
foo1 foo2
... 32768 times in total ...
foo1 foo2
\.
select c1, c2, count(*) from t1 group by c1, c2;

...gives me this in the log...

- ---- query is:
select c1, c2, count(*) from t1 group by c1, c2;

Too Large Allocation Request("!(0 < (size) && (size) <= (0xfffffff)):size=1718578990 [0x666f6f2e]", File: "mcxt.c", Line: 232)
!(0 < (size) && (size) <= (0xfffffff)) (0)

...

Leave out c2 and it works fine. Bad part is that it leaves the psql session
and the backend out sync, have to quit psql.

And now back to out regularly scheduled grouping error...

A good place to start debugging might be ExecGroupEveryTuple in nodeGroup.c
since that is where the code determines whether consecutive tuples belong to
the same "group."

Shouldn't be too hard to track down the failure there and then work back.

I would be inclined to agree with Tom's feeling about "psort" being the
culprit since that is setting up the tuples for the group node. Perhaps
put in some printfs to detect when the above function thinks it has a
different group and see what condition(s) triggered that "thought." From
there, grep around to find what is setting the variables for that condition.

I know, easier to say than do, just wish I could reproduce it here.

darrenk

From scrappy
Date: Sat, 17 Jan 1998 16:20:50 -0600 ()
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Subject: Re: [PORTS] Test and Set fixed for Linux/Alpha!
On 7 Jan 1998, Roland B. Roberts wrote:

"Ryan" == Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu> writes:
Ryan> Yes, I have tried both. A static function resulted in

Do you mean this as in (1) you tried both separately, or (2) you tried
them both together?
I tried them both seperately. Both fail because of the simple fact
that {no one can figure out,linux-alpha assembler does not support} local
labels in the assembly code needed for the spin lock code.
I don't have access to an Alpha, but on other architectures, I have
successfully used static inline together to keep a function from
appearing anyplace except in the particular module. Perhap gcc has a
problem on the Alpha?
The problem is that s_lock() needs to appear in multiple modules
through the binary, and as I mentioned above, the code to s_lock() can
only appear once in the entire resulting binary. Static/Inline functions
ought to work fine on Linux/Alpha, it is the assembly code that is
throwing a wrench in the works.
Hope this answers you questions.

- ----------------------------------------------------------------------------
"For to me to live is Christ, and to die is gain." |
--- Philippians 1:21 (KJV) |
- ----------------------------------------------------------------------------
Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
- ----------------------------------------------------------------------------
http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
- ----------------------------------------------------------------------------

From scrappy
Date: Mon, 19 Jan 1998 14:37:59 PST
From: "Mansoor *****" <mansoorl@hotmail.com>
Subject: INSTALLATION

This is to let you guys know that I was able to successfully install
POSTGRESQL on my Linux box.

Version: 6.2.1a
Linux: 2.0.30
Distribution: Slackware 3.4
System: i486

Thank you for creating the wonderful system and for keeping it FREE!
Mansoor.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From scrappy
Date: Tue, 20 Jan 1998 19:26:07 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [QUESTIONS] Installation of Postgres SQL
On 20 Jan 1998, Ed Dunnigan wrote:

checking for install... no
- No Install Script found - aborting.
Its looking for your 'install' command based on what your PATH is
set as...assuming, of course, that you have one?


Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Wed, 21 Jan 98 01:18:38 +0100
From: David Wetzel <dave@turbocat.de>
Subject: libpq on NT?

Hello!

I have written an adaptor for PostgreSQL to use it with NeXT's Enterprise
Objects Framework. I works fine on OPENSTEP for Mach 4.2 on both NeXT and Intel
hardware (I did not test on SUN hardware).

Now, I would like to port the libpq based framework to OPENSTEP for NT.

Has someone got libpq working on NT?

BTW: To download the adaptor visit my website.
_ _
_(_)(_)_ David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG,
_/ \_ Fax +49 33056 82835 NeXTmail dave@turbocat.de
(______) http://www.turbocat.de/
DEVELOPMENT * CONSULTING * ADMINISTRATION
WATCH OUT FOR TURBOFAX for OPENSTEP!

From scrappy
Date: Wed, 21 Jan 1998 08:41:31 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: -current version won't initdb under i386_solaris...

Anyone know what the heap_modifytuple error refers to down below?

The error is generated around line 884 of
backend/access/common/heaptuple.c, where 'repl[attoff]' != 'r'

Haven't had a chance to test this under FreeBSD yet, will hopefully try it
out tonight...


Script started on Wed 21 Jan 1998 09:35:41 AM AST
%./initdb --pglib=/loc/pgsql/lib --pgdata=/loc/pgsql/data
NAMEDATALEN=32
OIDNAMELEN=36
+ basename ./initdb
CMDNAME=initdb
+ sh -c postconfig
postconfig_result=
+ [ ! -z ]
debug=0
noclean=0
template_only=0
POSTGRES_SUPERUSERNAME=marc
+ [ 2 -gt 0 ]
+ echo --pglib=/loc/pgsql/lib
+ sed s/^--pglib=//
PGLIB=/loc/pgsql/lib
+ shift
+ [ 1 -gt 0 ]
+ echo --pgdata=/loc/pgsql/data
+ sed s/^--pgdata=//
PGDATA=/loc/pgsql/data
+ shift
+ [ 0 -gt 0 ]
+ [ -z /loc/pgsql/lib ]
+ [ -z /loc/pgsql/data ]
TEMPLATE=/loc/pgsql/lib/local1_template1.bki.source
GLOBAL=/loc/pgsql/lib/global1.bki.source
TEMPLATE_DESCR=/loc/pgsql/lib/local1_template1.description
GLOBAL_DESCR=/loc/pgsql/lib/global1.description
PG_HBA_SAMPLE=/loc/pgsql/lib/pg_hba.conf.sample
PG_GEQO_SAMPLE=/loc/pgsql/lib/pg_geqo.sample
+ [ ! -f /loc/pgsql/lib/local1_template1.bki.source ]
+ [ ! -f /loc/pgsql/lib/global1.bki.source ]
+ [ ! -f /loc/pgsql/lib/pg_hba.conf.sample ]
+ echo initdb: using /loc/pgsql/lib/local1_template1.bki.source as input to create the template database.
initdb: using /loc/pgsql/lib/local1_template1.bki.source as input to create the template database.
+ [ 0 -eq 0 ]
+ echo initdb: using /loc/pgsql/lib/global1.bki.source as input to create the global classes.
initdb: using /loc/pgsql/lib/global1.bki.source as input to create the global classes.
+ echo initdb: using /loc/pgsql/lib/pg_hba.conf.sample as the host-based authentication control file.
initdb: using /loc/pgsql/lib/pg_hba.conf.sample as the host-based authentication control file.
+ echo

+ [ -z marc ]
+ pg_id marc
POSTGRES_SUPERUID=100
+ [ 100 = NOUSER ]
+ pg_id
+ pg_id
+ [ 100 -ne 100 -a 100 -ne 0 ]
+ echo We are initializing the database system with username marc (uid=100).
We are initializing the database system with username marc (uid=100).
+ echo This user will own all the files and must also own the server process.
This user will own all the files and must also own the server process.
+ echo

+ umask 077
+ [ -f /loc/pgsql/data/PG_VERSION ]
+ [ ! -d /loc/pgsql/data ]
+ echo Creating Postgres database system directory /loc/pgsql/data
Creating Postgres database system directory /loc/pgsql/data
+ echo

+ mkdir /loc/pgsql/data
+ [ 0 -ne 0 ]
+ [ ! -d /loc/pgsql/data/base ]
+ echo Creating Postgres database system directory /loc/pgsql/data/base
Creating Postgres database system directory /loc/pgsql/data/base
+ echo

+ mkdir /loc/pgsql/data/base
+ [ 0 -ne 0 ]
+ rm -rf /loc/pgsql/data/base/template1
+ mkdir /loc/pgsql/data/base/template1
+ [ 0 -eq 1 ]
BACKEND_TALK_ARG=-Q
BACKENDARGS=-boot -C -F -D/loc/pgsql/data -Q
+ echo initdb: creating template database in /loc/pgsql/data/base/template1
initdb: creating template database in /loc/pgsql/data/base/template1
+ echo Running: postgres -boot -C -F -D/loc/pgsql/data -Q template1
Running: postgres -boot -C -F -D/loc/pgsql/data -Q template1
+ cat /loc/pgsql/lib/local1_template1.bki.source
+ sed -e s/postgres PGUID/marc 100/ -e s/NAMEDATALEN/32/g -e s/OIDNAMELEN/36/g -e s/PGUID/100/
+ postgres -boot -C -F -D/loc/pgsql/data -Q template1
ERROR: heap_modifytuple: repl is \-62
ERROR: heap_modifytuple: repl is \-62
^C%
script done on Wed 21 Jan 1998 09:36:25 AM AST

From scrappy
Date: Wed, 21 Jan 1998 15:11:44 -0600 (CST)
From: Thomas Ray Seals <rseals@ns.htc.net>
Subject: Need Help with 6.2.1 & FreeBSD

I have installed and complied 6.2.1 succesfully on a FreeBSD 2.2.1
server. I have enven been able to get initdb to run with no errors. I
haven't been successfully getting postmaster to run. When I start
postmaster , I get the bad command - core dump. I have confirmed from
the install documentation that the variable are set correctly for path
information etc. I have changed the pg_hba.conf to leave the door wide
open on request from users.

What am I doing wrong?

I have searched the web site and haven' been able to find much
regarding this.

Any help would be greatly appreciated.

Thanks,
Ray

From scrappy
Date: Wed, 21 Jan 1998 17:32:41 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Need Help with 6.2.1 & FreeBSD
On Wed, 21 Jan 1998, Thomas Ray Seals wrote:

I have installed and complied 6.2.1 succesfully on a FreeBSD 2.2.1
server. I have enven been able to get initdb to run with no errors. I
haven't been successfully getting postmaster to run. When I start
postmaster , I get the bad command - core dump. I have confirmed from
This one, if I'm drawing the proper conclusion, indicates that you don't
have SYSV IPC confiured into your kernel (SHMEM, etc) You have to rebuild
your kernel first...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 22 Jan 1998 09:55:48 -0600
From: Ray Seals <rayseals@midwestis.com>
Subject: RE: [PORTS] Need Help with 6.2.1 & FreeBSD

This is an install straight off the CD. So that wouldn't have the SYSV IPC configured????

Guess I'll be learning how to re-compile the kernel. Can you be a little more specific on what additional items need to be "turned on".

Thanks,
Ray

- -----Original Message-----
From: The Hermit Hacker [SMTP:scrappy@hub.org]
Sent: Wednesday, January 21, 1998 3:33 PM
To: Thomas Ray Seals
Cc: pgsql-ports@postgreSQL.org
Subject: Re: [PORTS] Need Help with 6.2.1 & FreeBSD
On Wed, 21 Jan 1998, Thomas Ray Seals wrote:

I have installed and complied 6.2.1 succesfully on a FreeBSD 2.2.1
server. I have enven been able to get initdb to run with no errors. I
haven't been successfully getting postmaster to run. When I start
postmaster , I get the bad command - core dump. I have confirmed from
This one, if I'm drawing the proper conclusion, indicates that you don't
have SYSV IPC confiured into your kernel (SHMEM, etc) You have to rebuild
your kernel first...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 22 Jan 1998 16:05:33 -0500 (EST)
From: Jeffrey Napolitano <laslo@bu.edu>
Subject: Installation of PostgreSQL

I installed postgresql 6.2.1 on the two following systems:

version: 6.2.1
OS: Linux 2.0.30
hardware: Pentium 166 with 64 MB RAM
cmple, install,
run regressions
successfully: Yes

version: 6.2.1
OS: Linux 2.0.30
hardware: Pentium 133 with 64 MB RAM
cmple, install,
run regressions
successfully: Yes

From scrappy
Date: Thu, 22 Jan 1998 16:44:12 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: fails to compile jdbc interface

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


Your name : Sachin More
Your email address : ssmore@ece.nwu.edu

Category : install: compile
Severity : serious

Summary: fails to compile jdbc interface

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

PostgreSQL version : 6.2.1

Compiler used : javac

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


Versions of other tools:
- ------------------------
gmake 3.71
jdk version 1.1.3 for HP-UX

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

Problem Description:
- --------------------
problem in creating the .jar file
here is the error generated:
jar -c0vf postgresql.jar postgresql/CallableStatement.class .....
....
....
adding: postgresql/PG_Object.class Assertion failed:GET_RESOURCE_ATTR( r1 ) == RaInt64, file /CLO/Components/SLLIC_LITE/Src/lwo/opt_driver.c, line 2514
SIGABRT 6* abort (generated by abort(3) routine)
location=7B03DF18.
stackbase=7B03AE6C, stackpointer=7B03B460
/opt/java/bin/../bin/PA_RISC/green_threads/jar[7]: 7437 Abort

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

Test Case:
- ----------
I dont know what all is needed but I guess you can reproduce
it if you compile the jdbc interface on HP-UX B.10.20 and JDK
supplied by HP version 1.1.3

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

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


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

From scrappy
Date: Thu, 22 Jan 1998 19:48:06 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Important Announcement

Hi...

As was previously announced, we are currently looking at upgrading
the server in all respects... well, totally replacing it is more like it.
Double the RAM, PII processor, 4x the disk space, increased bandwidth,
etc.

With this is mind, we are asking the PostgreSQL user community to
help offset the costs of this upgrade. Nobody is *required* to contribute
... the upgrade is going to happen regardless, as it is required, but I'd
prefer not to have to pay for *all* of it out of my pocket.

Towards this goal, starting with v6.3's release, we will be making
a CD distribution of PostgreSQL, as one means for users to be able to
contribute to the project.

There are two new pages on our web site that I ask/encourage
everyone to read through:

http://www.postgresql.org/fund-raising.shtml
http://www.postgresql.org/cd-dist.shtml

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 22 Jan 1998 20:03:24 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: free() error in libpq?

Bruce...

I'm just running tests under FreeBSD, and am seeing:
psql template1
psql in free(): warning: junk pointer, too high to make sense.
Welcome to the POSTGRESQL interactive sql monitor:

Are you seeing similar under BSDi? Anyone else?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 22 Jan 1998 19:17:15 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] free() error in libpq?

Bruce...

I'm just running tests under FreeBSD, and am seeing:
psql template1
psql in free(): warning: junk pointer, too high to make sense.
Welcome to the POSTGRESQL interactive sql monitor:

Are you seeing similar under BSDi? Anyone else?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Nope. Never seen it.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Fri, 23 Jan 98 01:31:09 +0100
From: David Wetzel <dave@turbocat.de>
Subject: Re: [PORTS] free() error in libpq?
From: The Hermit Hacker <<scrappy@hub.org>
psql template1
psql in free(): warning: junk pointer, too high to make sense.
Welcome to the POSTGRESQL interactive sql monitor: >
Are you seeing similar under BSDi? Anyone else?

No (postgresql-6.2.1)


dave@alice>psql template1

Welcome to the POSTGRESQL interactive sql monitor:

Please read the file COPYRIGHT for copyright terms of POSTGRESQL


type \? for help on slash commands

type \q to quit

type \g or terminate with semicolon to execute query

You are currently connected to the database: template1


EOFplate1=>

dave@alice>uname -a

NetBSD alice 1.3_BETA NetBSD 1.3_BETA (ALICE) #4: Tue Dec 16 20:40:47 CET
1997 root@alice:/usr/src/sys/arch/i386/compile/ALICE i386

<nofill>
- ---
_ _
_(_)(_)_ David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG,
_/ \_ Fax +49 33056 82835 NeXTmail dave@turbocat.de
(______) http://www.turbocat.de/
DEVELOPMENT * CONSULTING * ADMINISTRATION
WATCH OUT FOR TURBOFAX for OPENSTEP!</nofill>

From scrappy
Date: Fri, 23 Jan 1998 10:47:27 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Stupid C programming question...

gcc -I../../include -I../../backend -I/loc/include -I../../backend/port/sparc_solaris -Wall -Wmissing-prototypes -I.. -c index.c -o index.o
In file included from ../../include/postgres.h:40,
from index.c:26:
../../include/config.h:78: warning: `struct in_addr' declared inside \
parameter list
../../include/config.h:78: warning: its scope is only this definition or \
declaration,
../../include/config.h:78: warning: which is probably not what you want.


Can someone tell me what the above "error" means, and how to silence it?
It only happens, for me, under i386_solaris-gcc...

The line in question is:

/* Set to 1 if you have inet_aton() */
#undef HAVE_INET_ATON
#ifndef HAVE_INET_ATON
extern int inet_aton(const char *cp, struct in_addr * addr);
#endif

From scrappy
Date: Fri, 23 Jan 1998 10:09:20 -0600 (CST)
From: Alec Kloss <alec@d2si.com>
Subject: Re: [PORTS] Stupid C programming question...

It means that the compiler doesn't know what a "struct in_addr" is.
You almost certainly didn't include a header you needed.
man inet_aton will probably mention which headers you should be
including. I'd guess it's <arpa/inet.h>.

The Hermit Hacker said:
gcc -I../../include -I../../backend -I/loc/include -I../../backend/port/sparc_solaris -Wall -Wmissing-prototypes -I.. -c index.c -o index.o
In file included from ../../include/postgres.h:40,
from index.c:26:
../../include/config.h:78: warning: `struct in_addr' declared inside \
parameter list
../../include/config.h:78: warning: its scope is only this definition or \
declaration,
../../include/config.h:78: warning: which is probably not what you want.


Can someone tell me what the above "error" means, and how to silence it?
It only happens, for me, under i386_solaris-gcc...

The line in question is:

/* Set to 1 if you have inet_aton() */
#undef HAVE_INET_ATON
#ifndef HAVE_INET_ATON
extern int inet_aton(const char *cp, struct in_addr * addr);
#endif




From scrappy
Date: Fri, 23 Jan 1998 12:14:33 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Stupid C programming question...
On Fri, 23 Jan 1998, Alec Kloss wrote:

It means that the compiler doesn't know what a "struct in_addr" is.
You almost certainly didn't include a header you needed.
man inet_aton will probably mention which headers you should be
including. I'd guess it's <arpa/inet.h>.
I'm glad I disclaimered this with a "Stupid C..." subject :(

Thanks, have made appropriate changes for this and am runnign it
through now...
The Hermit Hacker said:
gcc -I../../include -I../../backend -I/loc/include -I../../backend/port/sparc_solaris -Wall -Wmissing-prototypes -I.. -c index.c -o index.o
In file included from ../../include/postgres.h:40,
from index.c:26:
../../include/config.h:78: warning: `struct in_addr' declared inside \
parameter list
../../include/config.h:78: warning: its scope is only this definition or \
declaration,
../../include/config.h:78: warning: which is probably not what you want.


Can someone tell me what the above "error" means, and how to silence it?
It only happens, for me, under i386_solaris-gcc...

The line in question is:

/* Set to 1 if you have inet_aton() */
#undef HAVE_INET_ATON
#ifndef HAVE_INET_ATON
extern int inet_aton(const char *cp, struct in_addr * addr);
#endif




From scrappy
Date: Fri, 23 Jan 1998 14:21:33 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [HACKERS] Current open 6.3 issues
On Fri, 23 Jan 1998, Andrew Martin wrote:

psql .psqlrc file startup(Andrew)
Unfortunately I simply don't have time to implement any of the nicer suggestions
for how this should work. I wish I did...
OK, what are we doing the .psqlrc. Can you send the old patch, or are
we dropping it for 6.3?

--
Bruce Momjian
maillist@candle.pha.pa.us
Here's the patch I supplied before:
Applied...

From scrappy
Date: Fri, 23 Jan 1998 19:57:39 -0800 (PST)
From: Brian Sanders <bsanders@netcom.com>
Subject: testlibpq3 returns incorrect results?

I just compiled version 6.2.1 on both Linux 2.0 and IRIX 5.3 systems and instead of the expected output, I got

type[0] = 23, size[0] = 4
type[1] = 700, size[1] = 4
type[2] = 604, size[2] = -1
tuple 0: got
i = (1 bytes) 49,
d = (5 bytes) 0.000003,
p = (5 bytes) 741550120 points boundbox = (hi=0.000000/0.000000, lo = 0.
000000,0.000000)
tuple 1: got
i = (1 bytes) 50,
d = (5 bytes) 0.000000,
p = (5 bytes) 741615656 points boundbox = (hi=0.000000/0.000000, lo = 0.
000000,0.000000)

(for comparison, the expected output is:)

tuple 0: got
i = (4 bytes) 1,
d = (4 bytes) 3.567000,
p = (4 bytes) 2 points boundbox = (hi=3.000000/4.000000, lo = 1.
000000,2.000000)
tuple 1: got
i = (4 bytes) 2,
d = (4 bytes) 89.050003,
p = (4 bytes) 2 points boundbox = (hi=4.000000/3.000000, lo = 2.
000000,1.000000)

Could someone help me figure out what's going on? (besides the fact that
DECLARE BINARY CURSOR doesn't seem to be working)

Brian

From scrappy
Date: Sat, 24 Jan 1998 02:18:00 -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: Sun, 25 Jan 1998 15:49:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [QUESTIONS] Instaling Postgresql...
On Sun, 25 Jan 1998, Anderson Ferreira Nobre wrote:

Hi guys,

I'm trying to install postgersql and when I type the following command line apears a error message:

# gmake all >& make.log &
[1] 17985
# ksh: make.log: bad file unit number
gmake all > make.log 2>&1 &

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Sun, 25 Jan 1998 14:54:26 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Port Bug Report: Result not "GROUPED BY" from SQL: select im,bn,count(adr) FROM logtmp GROUP BY im,bn;

We just applied the psort NULL fix yesterday, so please run some tests
on the new code before diving in.
select im,bn,count(adr) as cnt into TABLE qq FROM logtmp b where b.cmd='ad' GROUP BY im,bn;
This SQL works fine on postgres-6.1 and give me not right answer on Postgresql-6.2.1 + Patch 1..7
on two platforms - Linux(RH4.1) and Solaris 2.5.1
The sample table is here http://www.bizlink.ru/test/logtmp.dmp.gz
The result not groupped. Result should have about 89 rows, but it have 14410 rows on Linux

On Solaris it gives 89 rows (right) on the screen and
if I add "INTO TABLE qq" - gives me 93 rows
I believe this is the same problem at least a couple of us have reported under Linux. Unfortunately,
the problem is apparently not reproducible on all systems, and other developers do not see it. So,
difficult for them to believe, and harder to debug :)
I tried to reproduce on aix here and could not. I tried to get the above
test data, only I couldn't un-gzip it without errors.

But...with the following...

\connect username
create table t1 (c1 char(8), c2 char(8));
copy t1 from stdin;
foo1 foo2
... 32768 times in total ...
foo1 foo2
\.
select c1, c2, count(*) from t1 group by c1, c2;

...gives me this in the log...

---- query is:
select c1, c2, count(*) from t1 group by c1, c2;

Too Large Allocation Request("!(0 < (size) && (size) <= (0xfffffff)):size=1718578990 [0x666f6f2e]", File: "mcxt.c", Line: 232)
!(0 < (size) && (size) <= (0xfffffff)) (0)

...

Leave out c2 and it works fine. Bad part is that it leaves the psql session
and the backend out sync, have to quit psql.

And now back to out regularly scheduled grouping error...

A good place to start debugging might be ExecGroupEveryTuple in nodeGroup.c
since that is where the code determines whether consecutive tuples belong to
the same "group."

Shouldn't be too hard to track down the failure there and then work back.

I would be inclined to agree with Tom's feeling about "psort" being the
culprit since that is setting up the tuples for the group node. Perhaps
put in some printfs to detect when the above function thinks it has a
different group and see what condition(s) triggered that "thought." From
there, grep around to find what is setting the variables for that condition.

I know, easier to say than do, just wish I could reproduce it here.

darrenk




- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Sun, 25 Jan 1998 14:39:47 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] the 'money' type

Applied.
Thus spake Adam Fenn
Where can I find some documentation on how to use the money data type in
pgsql?
I never did get around to that. The code has some explanations. There
isn't really much. You create a type as money and you can assign values
such as '$123,456.78' (dollar sign optional) to it and it displays it
in the same format. You can do the usual comparisons on money types
as well as My Dear Aunt Sally with itself and some reasonable other
types such as int2, int4 and float. There is also a function in the
code to output money amounts in words ("One hundred fifty four dollars
and sixty five cents" for example) but I don't know if this is used
anywhere. I guess it's available for using as a function. I think
something like the following has to be added to the ibki file.

insert OID = xxx (cash_words_out PGUID 11 f t f 1 f 23 "0" 100 0 0 100 foo ba)

Then you would be able to do this.

darcy=> alter table xtest add column m money;
ADD
darcy=> update xtest set m = '123,456.78';
UPDATE 1
darcy=> select * from xtest;
d |m
-----------+-----------
Jan 07 1998|$123,456.78
(1 row)

darcy=> select cash_words_out(m) from xtest;

At this point it would have printed the amount in words.

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Sun, 25 Jan 1998 15:44:10 -0500
From: darrenk@insightdist.com (Darren King)
Subject: Re: [PORTS] GROUP BY Too Large Allocation Request Error

Downloading the latest snapshot from Jan 23...will test with that one.
We just applied the psort NULL fix yesterday, so please run some tests
on the new code before diving in.
But...with the following...

\connect username
create table t1 (c1 char(8), c2 char(8));
copy t1 from stdin;
foo1 foo2
... 32768 times in total ...
foo1 foo2
\.
select c1, c2, count(*) from t1 group by c1, c2;

...gives me this in the log...

---- query is:
select c1, c2, count(*) from t1 group by c1, c2;

Too Large Allocation Request("!(0 < (size) && (size) <= (0xfffffff)):size=1718578990 [0x666f6f2e]", File: "mcxt.c", Line: 232)
!(0 < (size) && (size) <= (0xfffffff)) (0)

...

Leave out c2 and it works fine. Bad part is that it leaves the psql session
and the backend out sync, have to quit psql.
From scrappy
Date: Sun, 25 Jan 1998 22:48:34 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [QUESTIONS] HP-UX 10.20 build gailure of latest snapshot

This does not belong in pgsql-questions@postgresql.org, as such is
responded to into pgsql-ports@postgresql.org...please remember this in the
future :(
On Sun, 25 Jan 1998, Stan Brown wrote:

The latest snapshot fails to configure on HP-UX 10.20 with the folowing
error:

configure: error: ./backend/port/dynloader/hpux.h: File not found

This is after choosing hppa-gcc as the target.
I've just added the file in...CVSup the newest code and try it out


Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Mon, 26 Jan 1998 12:53:51 -0600 (CST)
From: WAGNERP@UWSTOUT.EDU
Subject: postgresql 6.2.1 installed on Solbourne S4000

Don't know if anyone has installed Postgresql on Solbournes, so just
wanted to pass my experiences on in case it's useful to anyone.

Postgresql 6.2.1

Hardware - Solbourne S4000 (Sun Sparc clones)
OS Software - OS/MP 4.1B, derived from Sun OS 4.1
C Compiler - gcc 2.7.2
gmake 3.76.1
bison 1.25
flex 2.5.4

I chose the sunos4-gcc template, with default include and lib directories.

A few problems came up, with workarounds/solutions listed below:

gmake all
1) couldn't find <sys/select.h> - I tried copying one in from a DEC
Alpha workstation, but had other errors - for now, I just
included an empty file for this

gmake install
1) had to create /usr/local/pgsql by hand - I'd installed in another
directory but final install went to here
2) readline.h, keymaps.h, and chardefs.h were not found, even though
they were present on our system. This may be
because we have a rather funky gcc installation, essentially
copied in from some Suns due to gcc build problems with the outdated
cc we inherited on these Solbourne machines. These three .h
files were present in our .../gnu/include directory, but I
copied them into /usr/include just for the build to make them
be seen. libreadline.a was found but was out of date, so I ran
ranlib on it at this point.
3) got an error from ld when building psql that symbol ___ansi_fflush was
not found. I could not find any reference to this anywhere on our
systems, so I just created ansi_fflush.c with function __ansi_fflush
in it that calls regular fflush, compiled this to ansi_fflush.o,
and added it to the psql line in the makefile.

regression tests
int2, int4, oidint2, oidint4 - failed due to wording differences; no problem
float8 - one exp result was out of range, expected to be valid
geometry - some small, some larger differences (details on request)
tinterval - mostly larger differences; need to check this out more (details
on request)
horology - many differences, but mostly just PST vs. PDT (details on request)
random - assume differences here aren't a problem
select_views - many, but small (looks like rounding-type variations)

user testing
1) warning messages come back double - not sure what's causing this, as it
only happened after I reran gmake install to clean up some other
problems. Regular data returned is only displayed once.
2) something happened with readline - I can't get command recall. May
be related to the problems above - any ideas are welcome if you've
read this far.

Otherwise it seems to be working well. Looking forward to the 6.3
release!

Paul

*************************************************************************
* Paul J. Wagner / Assistant Professor of Computer Science *
* Department of Mathematics, Statistics, and Computer Science *
* Harvey Hall, Room 202J; 715-232-5001 *
* University of Wisconsin - Stout work - wagnerp@uwstout.edu *
* Menomonie, WI 54751 school - wagner@cs.umn.edu *
* www - http://www.mscs.uwstout.edu/~paul/home.html *
*************************************************************************

From scrappy
Date: Mon, 26 Jan 1998 19:38:18 -0500 (EST)
From: "Stan Brown" <stanb@awod.com>
Subject: Build failure for latest snapshot on HPUX

HPUX 10.20 PA-RISC.

There were a bunch of the folowing warnings:

In file included from ../../include/config.h:169,
from ../../include/postgres.h:40,
from main.c:18:
../../include/os.h:3: warning: `USE_POSIX_SIGNALS' redefined
*Initialization*:1: warning: this is the location of the previous definition

But here is the show stoper:

main.c:26: port-protos.h: No such file or directory

- --
Stan Brown stanb@netcom.com 770-996-6955
Factory Automation Systems
Atlanta Ga.
- --
Look, look, see Windows 95. Buy, lemmings, buy!
Pay no attention to that cliff ahead... Henry Spencer
(c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited.

From scrappy
Date: Mon, 26 Jan 1998 23:14:59 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Build failure for latest snapshot on HPUX
On Mon, 26 Jan 1998, Stan Brown wrote:

HPUX 10.20 PA-RISC.

There were a bunch of the folowing warnings:

In file included from ../../include/config.h:169,
from ../../include/postgres.h:40,
from main.c:18:
../../include/os.h:3: warning: `USE_POSIX_SIGNALS' redefined
*Initialization*:1: warning: this is the location of the previous definition
This may or may not make sense, but could you send the complete
error message, right from the 'cc' line onwards?
But here is the show stoper:

main.c:26: port-protos.h: No such file or directory
Can someone explain:

#if defined(NOFIXADE) || defined(NOPRINTADE)
# include "port-protos.h" /* for init_address_fixup() */
#endif

What is this init_address_fixup() *supposed* to be, because in
backend/ports/hpux/port.c, its an empty function...

From what I can tell, you should be able to go into your
template/hpux* files and remove the -DNOFIXADE and this should work. Can
you please test that and let me know? If I am correct, I'll remove that
from the template files over here...


Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Mon, 26 Jan 1998 22:25:26 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Build failure for latest snapshot on HPUX
On Mon, 26 Jan 1998, Stan Brown wrote:

HPUX 10.20 PA-RISC.

There were a bunch of the folowing warnings:

In file included from ../../include/config.h:169,
from ../../include/postgres.h:40,
from main.c:18:
../../include/os.h:3: warning: `USE_POSIX_SIGNALS' redefined
*Initialization*:1: warning: this is the location of the previous definition
This may or may not make sense, but could you send the complete
error message, right from the 'cc' line onwards?
But here is the show stoper:

main.c:26: port-protos.h: No such file or directory
Can someone explain:

#if defined(NOFIXADE) || defined(NOPRINTADE)
# include "port-protos.h" /* for init_address_fixup() */
#endif
Do a gid/eid on NOFIXADE, or see fixade.h. Something about alignment on
hpS500 alignment. I say chuck it. It is probably very old, and our HP
port stuff is really messy at this point with hpux 9, 10, 10.1, and
10.2.
What is this init_address_fixup() *supposed* to be, because in
backend/ports/hpux/port.c, its an empty function...

From what I can tell, you should be able to go into your
template/hpux* files and remove the -DNOFIXADE and this should work. Can
you please test that and let me know? If I am correct, I'll remove that
from the template files over here...


Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org


- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Mon, 26 Jan 1998 23:35:11 -0500 (EST)
From: "Stan Brown" <stanb@awod.com>
Subject: HPUX-CC port

Ifound the problem that was forcing a build with hpux-cc speceified to
still use gcc. Unfortunately this just opened up another can of worms.
here is the sad tale of woe :-(


Script started on Mon Jan 26 23:30:21 1998
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$ gmake
gmake -C lextest all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/lextest'
flex scan.l
cc -c lex.yy.c
cc -c lextest.c
cc -o lextest lex.yy.o lextest.o
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/lextest'
gmake -C utils all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/utils'
cc -I../include -I../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../include -c version.c -o version.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/utils'
gmake -C backend all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C access all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/access'
gmake -C common SUBSYS.o
gmake[3]: Entering directory `/home/stan/work/pgsql/src/backend/access/common'
gmake -C ../.. fmgr.h
gmake[4]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C utils fmgr.h
gmake[5]: Entering directory `/home/stan/work/pgsql/src/backend/utils'
sh Gen_fmgrtab.sh ../../include/catalog/pg_proc.h
gmake[5]: Leaving directory `/home/stan/work/pgsql/src/backend/utils'
cp utils/fmgr.h .
gmake[4]: Leaving directory `/home/stan/work/pgsql/src/backend'
cc -I../../../include -I../../../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../.. -c heaptuple.c -o heaptuple.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
gmake[3]: *** [heaptuple.o] Error 1
gmake[3]: Leaving directory `/home/stan/work/pgsql/src/backend/access/common'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/access'
gmake[1]: *** [access.dir] Error 2
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/backend'
gmake: *** [all] Error 2
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$

script done on Mon Jan 26 23:32:21 1998

Any ideas here?

- --
Stan Brown stanb@netcom.com 770-996-6955
Factory Automation Systems
Atlanta Ga.
- --
Look, look, see Windows 95. Buy, lemmings, buy!
Pay no attention to that cliff ahead... Henry Spencer
(c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited.

From scrappy
Date: Tue, 27 Jan 1998 01:07:00 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] HPUX-CC port
On Mon, 26 Jan 1998, Stan Brown wrote:

Ifound the problem that was forcing a build with hpux-cc speceified to
still use gcc. Unfortunately this just opened up another can of worms.
here is the sad tale of woe :-(


Script started on Mon Jan 26 23:30:21 1998
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$ gmake
gmake -C lextest all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/lextest'
flex scan.l
cc -c lex.yy.c
cc -c lextest.c
cc -o lextest lex.yy.o lextest.o
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/lextest'
gmake -C utils all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/utils'
cc -I../include -I../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../include -c version.c -o version.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/utils'
gmake -C backend all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C access all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/access'
gmake -C common SUBSYS.o
gmake[3]: Entering directory `/home/stan/work/pgsql/src/backend/access/common'
gmake -C ../.. fmgr.h
gmake[4]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C utils fmgr.h
gmake[5]: Entering directory `/home/stan/work/pgsql/src/backend/utils'
sh Gen_fmgrtab.sh ../../include/catalog/pg_proc.h
gmake[5]: Leaving directory `/home/stan/work/pgsql/src/backend/utils'
cp utils/fmgr.h .
gmake[4]: Leaving directory `/home/stan/work/pgsql/src/backend'
cc -I../../../include -I../../../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../.. -c heaptuple.c -o heaptuple.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
Fixed. Or at least I think it is.

Basically, go into makefiles/Makefile.hpux and remove the line
that has -DUSE_POSIX_SIGNALS, which will fix that problem.

Also, go into template/hpux* and get rid of the -DNOFIXADE

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Tue, 27 Jan 1998 00:08:50 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] HPUX-CC port
Ifound the problem that was forcing a build with hpux-cc speceified to
still use gcc. Unfortunately this just opened up another can of worms.
here is the sad tale of woe :-(


Script started on Mon Jan 26 23:30:21 1998
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$ gmake
gmake -C lextest all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/lextest'
flex scan.l
cc -c lex.yy.c
cc -c lextest.c
cc -o lextest lex.yy.o lextest.o
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/lextest'
gmake -C utils all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/utils'
cc -I../include -I../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../include -c version.c -o version.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/utils'
gmake -C backend all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C access all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/access'
gmake -C common SUBSYS.o
gmake[3]: Entering directory `/home/stan/work/pgsql/src/backend/access/common'
gmake -C ../.. fmgr.h
gmake[4]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C utils fmgr.h
gmake[5]: Entering directory `/home/stan/work/pgsql/src/backend/utils'
sh Gen_fmgrtab.sh ../../include/catalog/pg_proc.h
gmake[5]: Leaving directory `/home/stan/work/pgsql/src/backend/utils'
cp utils/fmgr.h .
gmake[4]: Leaving directory `/home/stan/work/pgsql/src/backend'
cc -I../../../include -I../../../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../.. -c heaptuple.c -o heaptuple.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
gmake[3]: *** [heaptuple.o] Error 1
gmake[3]: Leaving directory `/home/stan/work/pgsql/src/backend/access/common'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/access'
gmake[1]: *** [access.dir] Error 2
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/backend'
gmake: *** [all] Error 2
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$

script done on Mon Jan 26 23:32:21 1998

Any ideas here?
AIX is having problems with this too. It is the heap_getattr macro that
is causing problems, probably the (void) casting we added to remove
warnings about unused args from gcc. Please try changing the (void) to
(bool) and see what happens. If it works, we need a macro like:

#if ! defined(hp) && !defined(aix)
#define dummy_return void
#else
#define dummy_return bool
#endif

and we then use (dummy_return) in places like this macro.


- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Tue, 27 Jan 1998 10:36:45 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] HPUX-CC port
Ifound the problem that was forcing a build with hpux-cc speceified to
still use gcc. Unfortunately this just opened up another can of worms.
here is the sad tale of woe :-(


Script started on Mon Jan 26 23:30:21 1998
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$ gmake
gmake -C lextest all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/lextest'
flex scan.l
cc -c lex.yy.c
cc -c lextest.c
cc -o lextest lex.yy.o lextest.o
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/lextest'
gmake -C utils all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/utils'
cc -I../include -I../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../include -c version.c -o version.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/utils'
gmake -C backend all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C access all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/access'
gmake -C common SUBSYS.o
gmake[3]: Entering directory `/home/stan/work/pgsql/src/backend/access/common'
gmake -C ../.. fmgr.h
gmake[4]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C utils fmgr.h
gmake[5]: Entering directory `/home/stan/work/pgsql/src/backend/utils'
sh Gen_fmgrtab.sh ../../include/catalog/pg_proc.h
gmake[5]: Leaving directory `/home/stan/work/pgsql/src/backend/utils'
cp utils/fmgr.h .
gmake[4]: Leaving directory `/home/stan/work/pgsql/src/backend'
cc -I../../../include -I../../../backend -I/opt/gnu/lib -W l,-E -Ae -DNOFIXADE -DUSE_POSIX_SIGNALS -I../.. -c heaptuple.c -o heaptuple.o
cpp: "os.h", line 3: warning 2001: Redefinition of macro USE_POSIX_SIGNALS.
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
OK, I just applied a GCC-specific patch so only gcc (void)'s the ?: args
to prevent the compile warning. Give it a try.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Tue, 27 Jan 1998 16:35:50 GMT
From: Andrew Martin <martin@biochemistry.ucl.ac.uk>
Subject: Re: [PORTS] Re: [QUESTIONS] Instaling Postgresql...
On Sun, 25 Jan 1998, Anderson Ferreira Nobre wrote:

Hi guys,

I'm trying to install postgersql and when I type the following command line apears a error message:

# gmake all >& make.log &
[1] 17985
# ksh: make.log: bad file unit number
gmake all > make.log 2>&1 &
Assuming you are using a Bourne-like shell...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Andrew

- ----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

From scrappy
Date: Tue, 27 Jan 1998 12:05:55 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Re: [QUESTIONS] Instaling Postgresql...
On Tue, 27 Jan 1998, Andrew Martin wrote:
On Sun, 25 Jan 1998, Anderson Ferreira Nobre wrote:

Hi guys,

I'm trying to install postgersql and when I type the following command line apears a error message:

# gmake all >& make.log &
[1] 17985
# ksh: make.log: bad file unit number
gmake all > make.log 2>&1 &
Assuming you are using a Bourne-like shell...
The error he presented indicates he's using ksh, which, and
correct me if I'm wrong, uses the same redirect syntax as sh/bash...no?

From scrappy
Date: Tue, 27 Jan 1998 22:24:22 -0500 (EST)
From: "Stan Brown" <stanb@awod.com>
Subject: Progress on HP-UX port (but not success)

Todays snapshot fixes the problems I had yesterday compling the
hpux-gcc port. But it fails later. Here is the make script.:


gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/lib'
gmake -C libpq all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/libpq'
gcc -I../../include -I../../backend -I/opt/gnu/include -Wall -Wmissing-prototypes -I.. -c pqcomm.c -o pqcomm.o
pqcomm.c: In function `StreamServerPort':
pqcomm.c:601: warning: implicit declaration of function `bzero'
pqcomm.c:605: structure has no member named `sun_len'
pqcomm.c: In function `StreamOpen':
pqcomm.c:760: structure has no member named `sun_len'
gmake[2]: *** [pqcomm.o] Error 1
gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/libpq'
gmake[1]: *** [libpq.dir] Error 2
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/backend'
gmake: *** [all] Error 2
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$

script done on Tue Jan 27 22:21:32 1998

- --
Stan Brown stanb@netcom.com 770-996-6955
Factory Automation Systems
Atlanta Ga.
- --
Look, look, see Windows 95. Buy, lemmings, buy!
Pay no attention to that cliff ahead... Henry Spencer
(c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited.

From scrappy
Date: Tue, 27 Jan 1998 22:32:39 -0500 (EST)
From: "Stan Brown" <stanb@awod.com>
Subject: HPUX-CC port compile failure.

I am still having trouble geting todays snapshot to compile on HPUX
10.20 using h{'s C. It know corectly tries to use cc instead of gcc,
but it still fails in the folowing manner:


Script started on Tue Jan 27 22:29:14 1998
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$ gmake
gmake -C lextest all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/lextest'
flex scan.l
cc -c lex.yy.c
cc -c lextest.c
cc -o lextest lex.yy.o lextest.o
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/lextest'
gmake -C utils all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/utils'
cc -I../include -I../backend -I/opt/gnu/include -W l,-E -Ae -I../include -c version.c -o version.o
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/utils'
gmake -C backend all
gmake[1]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C access all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/access'
gmake -C common SUBSYS.o
gmake[3]: Entering directory `/home/stan/work/pgsql/src/backend/access/common'
gmake -C ../.. fmgr.h
gmake[4]: Entering directory `/home/stan/work/pgsql/src/backend'
gmake -C utils fmgr.h
gmake[5]: Entering directory `/home/stan/work/pgsql/src/backend/utils'
sh Gen_fmgrtab.sh ../../include/catalog/pg_proc.h
gmake[5]: Leaving directory `/home/stan/work/pgsql/src/backend/utils'
cp utils/fmgr.h .
gmake[4]: Leaving directory `/home/stan/work/pgsql/src/backend'
cc -I../../../include -I../../../backend -I/opt/gnu/include -W l,-E -Ae -I../.. -c heaptuple.c -o heaptuple.o
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
cc: "heaptuple.c", line 876: error 1553: Incompatible types in second and third operands of conditional expression (?:).
gmake[3]: *** [heaptuple.o] Error 1
gmake[3]: Leaving directory `/home/stan/work/pgsql/src/backend/access/common'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/access'
gmake[1]: *** [access.dir] Error 2
gmake[1]: Leaving directory `/home/stan/work/pgsql/src/backend'
gmake: *** [all] Error 2
]0;stan@kodiak;/home/stan/work/pgsql/srcstan@kodiak:/home/stan/work/pgsql/src
$

script done on Tue Jan 27 22:29:41 1998

- --
Stan Brown stanb@netcom.com 770-996-6955
Factory Automation Systems
Atlanta Ga.
- --
Look, look, see Windows 95. Buy, lemmings, buy!
Pay no attention to that cliff ahead... Henry Spencer
(c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited.

From scrappy
Date: Tue, 27 Jan 1998 22:35:34 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Progress on HP-UX port (but not success)
Todays snapshot fixes the problems I had yesterday compling the
hpux-gcc port. But it fails later. Here is the make script.:


gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/lib'
gmake -C libpq all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/libpq'
gcc -I../../include -I../../backend -I/opt/gnu/include -Wall -Wmissing-prototypes -I.. -c pqcomm.c -o pqcomm.o
pqcomm.c: In function `StreamServerPort':
pqcomm.c:601: warning: implicit declaration of function `bzero'
pqcomm.c:605: structure has no member named `sun_len'
pqcomm.c: In function `StreamOpen':
pqcomm.c:760: structure has no member named `sun_len'
This was fixed today. Check tomorrow's snapshot.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Tue, 27 Jan 1998 23:43:06 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Progress on HP-UX port (but not success)
On Tue, 27 Jan 1998, Stan Brown wrote:

Todays snapshot fixes the problems I had yesterday compling the
hpux-gcc port. But it fails later. Here is the make script.:


gmake[2]: Leaving directory `/home/stan/work/pgsql/src/backend/lib'
gmake -C libpq all
gmake[2]: Entering directory `/home/stan/work/pgsql/src/backend/libpq'
gcc -I../../include -I../../backend -I/opt/gnu/include -Wall -Wmissing-prototypes -I.. -c pqcomm.c -o pqcomm.o
pqcomm.c: In function `StreamServerPort':
pqcomm.c:601: warning: implicit declaration of function `bzero'
pqcomm.c:605: structure has no member named `sun_len'
pqcomm.c: In function `StreamOpen':
pqcomm.c:760: structure has no member named `sun_len'
I believe that today's work by Bruce on the sun_len stuff for
Linux should address your problem also...next snapshot :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Tue, 27 Jan 1998 22:27:43 -0600
From: Tim Goeke <tgoeke@xpressway.com>
Subject: Compiling under RedHat 5.0??

Well, I may have really messed up...

I installed RedHat 5.0 and my PostgreSQL 6.2.1 install didn't come up when
I rebooted. So, I thought I would re-compile and just re-install the
binaries. (Since the libc is changing).

Unfortunately, when I recompile, I get linker errors. I am going to
download all the new patches, re-run configure, and then do a clean compile.

If anyone has any other suggestions, I would love to hear them.

Also, what do I do if my data does not come back??

TIA

- -Tim Goeke

From scrappy
Date: Wed, 28 Jan 1998 18:18:35 GMT
From: Andrew Martin <martin@biochemistry.ucl.ac.uk>
Subject: Re: [PORTS] Re: [QUESTIONS] Instaling Postgresql...
On Tue, 27 Jan 1998, Andrew Martin wrote:
On Sun, 25 Jan 1998, Anderson Ferreira Nobre wrote:

Hi guys,

I'm trying to install postgersql and when I type the following command line apears a error message:

# gmake all >& make.log &
[1] 17985
# ksh: make.log: bad file unit number
gmake all > make.log 2>&1 &
Assuming you are using a Bourne-like shell...
The error he presented indicates he's using ksh, which, and
correct me if I'm wrong, uses the same redirect syntax as sh/bash...no?
Honestly don't know (I've never used ksh) - I only said 'cos I noticed
it was ksh and didn't know what the syntax was for ksh.

Best wishes,

Andrew

- ----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

From scrappy
Date: Thu, 29 Jan 1998 08:39:59 +1300 (NZDT)
From: Peter Stockwell <peter@sanger.otago.ac.nz>
Subject: Re: [PORTS] Re: [QUESTIONS] Instaling Postgresql... (fwd)
On Tue, 27 Jan 1998, Andrew Martin wrote:
On Sun, 25 Jan 1998, Anderson Ferreira Nobre wrote:

Hi guys,

I'm trying to install postgersql and when I type the following command line apears a error message:

# gmake all >& make.log &
[1] 17985
# ksh: make.log: bad file unit number
gmake all > make.log 2>&1 &
Assuming you are using a Bourne-like shell...
The error he presented indicates he's using ksh, which, and
correct me if I'm wrong, uses the same redirect syntax as sh/bash...no?
Honestly don't know (I've never used ksh) - I only said 'cos I noticed
it was ksh and didn't know what the syntax was for ksh.
On a DEC/alpha OSF man ksh includes the following:
[...]
Input/Output.

Before a command is executed, its input and output may be redirected using
a special notation interpreted by the shell. The following may appear any-
where in a simple-command or may precede or follow a command and are not
passed on to the invoked command. Command substitution, parameter expan-
sion, and arithmetic substitution occur before word or digit is used except
as noted below. File name generation occurs only if the shell is interac-
tive and the pattern matches a single file, Field splitting is not per-
formed.

< word Use file word as standard input (file descriptor 0).
word Use file word as standard output (file descriptor 1). If the
file does not exist then it is created. If the file exists,
and the noclobber option is on, this causes an error; other-
wise, it is truncated to zero length.
word Sames as >, except that it overrides the noclobber option.
word Use file word as standard output. If the file exists then
output is appended to it (by first seeking to the end-of-
file); otherwise, the file is created.

<> word Open file word for reading and writing as standard input.

<<[-]word The shell input is read up to a line that is the same as word
after any quoting has been removed remove, or to an end-of-
file. No parameter substitution, command substitution,
arithmetic substitution or file name generation is performed
on word. The resulting document, called a here-document,
becomes the standard input. If any character of word is
quoted, then no interpretation is placed upon the characters
of the document; otherwise, parameter expansion, command sub-
stitution, and arithmetic substitution occur, \new-line is
ignored, and \ must be used to quote the characters \, $, .
If - is appended to <<, then all leading tabs are stripped
from word and from the document.

<& digit The standard input is duplicated from file descriptor digit
(see dup(2)). Similarly for the standard output using
&digit.
<&- The standard input is closed. Similarly for the standard
output using >&-.

<&p The input from the co-process is moved to standard input.
&p The output to the co-process is moved to standard output.
If one of the above is preceded by a digit, then the file descriptor number
referred to is that specified by the digit (instead of the default 0 or 1).
For example:

... 2>&1

means file descriptor 2 is to be opened for writing as a duplicate of file
descriptor 1.

The order in which redirections are specified is significant. The shell
evaluates each redirection in terms of the ("filedescriptor" association at
the time of evaluation. For example:

... 1>fname 2>&1

first associates file descriptor 1 with file fname. It then associates
file descriptor 2 with the file associated with file descriptor 1 (i.e.
fname). If the order of redirections were reversed, file descriptor 2
would be associated with the terminal (assuming file descriptor 1 had been)
and then file descriptor 1 would be associated with file fname.

If a command is followed by & and job control is not active, then the
default standard input for the command is the empty file /dev/null. Other-
wise, the environment for the execution of a command contains the file
descriptors of the invoking shell as modified by input/output specifica-
tions.

KSH file redirection thus appears more complex than either sh or csh
and in the case in point led the shell to interpret make.log as a unit
number, hence expecting a digit.

Peter A. Stockwell

peter@sanger.otago.ac.nz

From scrappy
Date: Wed, 28 Jan 1998 19:56:57 +0000
From: Ivan Cornell <ivan.cornell@framestore.co.uk>
Subject: IRIX n32/64 Failure

============================================================================

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



Your name : Ivan Cornell
Your email address : ivan.cornell@framestore.co.uk


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

Operating System (example: Linux 2.0.26 ELF) : IRIX 6.4

PostgreSQL version (example: PostgreSQL-6.2.1): PostgreSQL-6.2.1

Compiler used (example: gcc 2.7.2) : IRIX IDO 7.2 cc


Please enter a FULL description of your problem:
- ------------------------------------------------
Compiling postgresql as a n32 or 64 executable fails.

Initdb fails when attempting to run postgres: - the following is an
example of what occurs.

< 128 rc postgresql-6.2.1/src> postgres -boot -C -F
- -D/usr/local/pgsql/data -Q template1
Bus error (core dumped)
< 129 rc postgresql-6.2.1/src> dbx /usr/local/pgsql/bin/postgres
dbx version 7.2 Aug 29 1997 03:27:55
PC value from core file (0x10111df4) is not part of the program.
Assuming return register value (0x10111df4) usable to locate PC.
Core from signal SIGBUS: Bus error
(dbx) where
0 AllocSetInit(0x10156518, 0x0, 0x0, 0x0, 0x1, 0x6, 0xdb37598, 0x51)
["/castle/people/ivan/postgresql-6.2.1/src/backend/utils/mmgr/aset.c":116,
0x10111df4]
1 OrderedElemPushInto(0x10156518, 0x0, 0x0, 0x0, 0x1, 0x6, 0xdb37598,
0x51)
["/castle/people/ivan/postgresql-6.2.1/src/backend/utils/mmgr/oset.c":147,
0x10113c18]
2 EnableMemoryContext(0x1, 0x0, 0x0, 0x0, 0x1, 0x6, 0xdb37598, 0x51)
["/castle/people/ivan/postgresql-6.2.1/src/backend/utils/mmgr/mcxt.c":169,
0x10112298]
3 InitPostgres(0x10156518, 0x0, 0x0, 0x0, 0x1, 0x6, 0xdb37598, 0x51)
["/castle/people/ivan/postgresql-6.2.1/src/backend/utils/init/postinit.c":544,
0x10111b80]
4 BootstrapMain(0x7, 0xffffffae88, 0x0, 0x0, 0x1, 0x6, 0xdb37598,
0x51)
["/castle/people/ivan/postgresql-6.2.1/src/backend/bootstrap/bootstrap.c":415,
0x10049240]
5 main(0x7, 0xffffffae88, 0x0, 0x0, 0x1, 0x6, 0xdb37598, 0x51)
["/castle/people/ivan/postgresql-6.2.1/src/backend/main/main.c":74,
0x1007dda0]
6 __start()
["/xlv22/ficus-jan23/work/irix/lib/libc/libc_64_M4/csu/crt1text.s":166,
0x10024f48]


This is for your information, as several people have been reporting
problems on the questions mailing list & I'm not sure a full breakdown
of the error has been given. I am waiting on 6.3 beta being released
next week before tackling this any more but am prepaerd to have a deeper
go then.

- --
Ivan Cornell, FrameStore Ltd
ivan.cornell@framestore.co.uk

From scrappy
Date: Wed, 28 Jan 1998 15:19:50 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] IRIX n32/64 Failure
On Wed, 28 Jan 1998, Ivan Cornell wrote:


This is for your information, as several people have been reporting
problems on the questions mailing list & I'm not sure a full breakdown
of the error has been given. I am waiting on 6.3 beta being released
next week before tackling this any more but am prepaerd to have a deeper
go then.
You might want to grab the snapshot available at
ftp.postgresql.org/pub, which is what v6.3beta will be (with some
changes) starting on ... ack ... this weekend. Time flies when one is
having fun and all that :)

There have been substantial changes since v6.2.1 came out that
*may* (or may not) have improved your above situation. may as well get as
early a start on this as possible.



From scrappy
Date: Wed, 28 Jan 1998 17:11:06 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Memory Leak in JDBC driver during query

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


Your name : Kevin Smilak
Your email address : kcsmilak@ucla.edu

Category : runtime: front-end: Java
Severity : serious

Summary: Memory Leak in JDBC driver during query

System Configuration
- --------------------
Operating System : Linux 2.0.32 Red Hat 5

PostgreSQL version : 6.1.1

Compiler used : binary

Hardware:
- ---------
Pentium 166 64 megs
Pentium 133 32 megs

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


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

Problem Description:
- --------------------
Durring a execute() where a Resultset is returned or
executeQuery(), about 10k is allocated and never freed.
Even if the ResultSet, Statement, and Connection are closed
and refrences removed, the memory remains allocated. Attached
is sample code in Java which creates the problem. Replace
the database,username,password, and query to allow it to
execute on your machine. Use top or some other resource
monitor to see the memory leak grow.

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

Test Case:
- ----------
import java.sql.* ;
import java.util.Hashtable ;

/**
* This class demonstrates a memory leak in either the JDBC or postgres JDBC driver.
* This has only been tested on Linux RedHat 5.0 using JDK1.1 and PostgreSQL.
*/

public class JDBCbug {

public String query = "select * from table" ;
public String driver = "postgresql.Driver" ;
public String databaseURL = "jdbc:postgresql://localhost:5432/database" ;
public String username = "postgres" ;
public String password = "pass" ;

public JDBCbug() {
try {

/* load the JDBC Driver class */
Class.forName(driver);

while (true) {

try {

/* open a connection to the Database */
Connection connection ;
connection = DriverManager.getConnection(databaseURL, username, password);
connection.setAutoCommit(true) ;

/* execute query on database */
Statement statement ;
statement = connection.createStatement() ;

/**
* Here is the memory leak. Remove this line and no problems. Leave this
* in and the program will grab ~10K every time this line is executed and
* never let it go.
*/

/* start memory leak code */

statement.execute(query) ;

/* end memory leak code */

/* walk through results returned */
ResultSet resultSet ;
while ((resultSet = statement.getResultSet()) != null) {
ResultSetMetaData metaData = resultSet.getMetaData() ;
int cols = metaData.getColumnCount() ;
Hashtable h = new Hashtable(cols) ;
while (resultSet.next()) {
for(int i=1;i<=cols;i++) {
Object obj = resultSet.getObject(i) ;
h.put(metaData.getColumnLabel(i), obj) ;
obj = null ;
}
System.out.println(h) ;
h = null ;
metaData = null ;
}

resultSet.close() ;
resultSet = null ;
statement.getMoreResults() ;
}

/* close SQL statement and connection */
statement.close() ;
statement = null ;
connection.commit() ;
connection.close() ;
connection = null ;

}

catch (SQLException sqle) {
sqle.printStackTrace() ;
System.exit(1) ;
}

/* garbage collect any leftover resources */
System.gc() ;
}

}
catch (ClassNotFoundException cnfe) {
cnfe.printStackTrace() ;
System.exit(1) ;
}

}

public static void main(String args[]) {
new JDBCbug() ;
}
}


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

Solution:
- ---------
Make sure all resources are deallocated when ResultSet
objects are closed or garbage collected.

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

From scrappy
Date: Wed, 28 Jan 1998 18:18:02 -0500
From: maddog <sosa19@idt.net>
Subject: linux compiling error

If PostgreSQL failed to compile on your computer or you found a bug that

is likely to be specific to one platform then please fill out this form
and e-mail it to pgsql-ports@postgresql.org.

To report any other bug, fill out the form below and e-mail it to
pgsql-bugs@postgresql.org.

If you not only found the problem but solved it and generated a patch
then e-mail it to pgsql-patches@postgresql.org instead. Please use the
command "diff -c" to generate the patch.

You may also enter a bug report at http://www.postgresql.org/ instead of

e-mail-ing this form.

============================================================================

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



Your name :Antonio Sosa
Your email address :sosa19@idt.net


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

Operating System (example: Linux 2.0.26 ELF) : Linux 2.0.30 ELF

PostgreSQL version (example: PostgreSQL-6.2) : PostgreSQL-6.2

Compiler used (example: gcc 2.7.2) : gcc 2.7.2.3


Please enter a FULL description of your problem:
- ------------------------------------------------
Configure for linux-elf runs fine but when I type make all, I produce an
error

make[3]: Leaving directory `/usr/src/pgsql/src/interfaces/libpq'
gcc -I../../include -I/usr/include/ncurses -O2 -Wall
- -Wmissing-prototypes -Dl
pg_dump.c: In function `dumpOprs':
pg_dump.c:1747: parse error before `['
pg_dump.c:1797: parse error before `restrict'
pg_dump.c:1830: parse error before `restrict'
make[2]: *** [pg_dump.o] Error 1
make[2]: Leaving directory `/usr/src/pgsql/src/bin/pg_dump'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/pgsql/src/bin'
make: *** [all] Error 2

this is produced after about ten minutes compiling. Any ideas. I tried
the
best I could to see if I have all the correct libraries and as far as I
see
I have flex, ncurses, etc loaded just fine and in the directories that
the
Makefile is looking for. I really want to try this database manager out
and
would appreciate any help you may have.

Thanks, in advance.




Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------
load slackware linux 3.4 and try to install postgresql 6.2, pick
template
linux_elf and run make all.




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

From scrappy
Date: Wed, 28 Jan 1998 17:59:23 -0800 (PST)
From: Douglas Marsh <dmarsh@spscc.ctc.edu>
Subject: cygwin32 port??

Have you any knowledge of a good port of postgresql to work under
cygwin32 (Cygnus's port of GNU C/C++ and bunch of Unix-like support
tools, bash/grep/tee/flex/tcl/awk/etc...)???

I am interested in an attempting! Spoke with the Mermit Hacket
(scrappy@hub.org) and he suggest that I mail this question to you!. He (I
guess he did) also updated the make files to recongnize the cygnus
system.. I may be wrong maybe someone eelse did that. I plan to (after I
send this message off) DL the lattest 6.3 version and install the src
files and attempt a ./configure... thanks (in advanced) much for any help
that you might be able to throw my way...

- --Douglas Marsh

From scrappy
Date: Wed, 28 Jan 1998 22:43:11 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Wed, 28 Jan 1998, Douglas Marsh wrote:

I am interested in an attempting! Spoke with the Mermit Hacket
Hermit Hacker, thank you...
(scrappy@hub.org) and he suggest that I mail this question to you!. He (I
guess he did) also updated the make files to recongnize the cygnus
Yes, I did...


Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Wed, 28 Jan 1998 19:50:03 -0800 (PST)
From: Douglas Marsh <dmarsh@spscc.ctc.edu>
Subject: Re: [PORTS] cygwin32 port??

Heehee have a case of mistaken identity??

Anywhays.. modigied the configure (and configure.in) and got VERY far...
It was in the middle of the config process.. make the make files.. then
it tried to create links (cygwin32 only support symblic links at this
time, so I wrote a quick script to fix that. ln.exe is now lnln.exe and
ln script is smart to add -s and check if $1 is -1 and shift that off and
then call lnln.exe -s $@)...
here is where it stops:


linking ./backend/port/tas/i386_solaris.s to backend/port/tas.s
linking ./backend/port/dynloader/cygwin32.c to backend/port/dynloader.c
configure: error: ./backend/port/dynloader/cygwin32.c: File not found
/d/home/user/work/postgresql/pgsql/src #

(i've done this twice.. the first time I ran and pick the linux
template.. the second time I picked generic... I will continue to "hack"
at it...)....

Is there something I should know about the above directory!?
./backend/port/dynloader/cygwin32.c or do you have a suggested here!? Do
you want the cache file or any other files generated by ./configure ??

From scrappy
Date: Wed, 28 Jan 1998 19:56:33 -0800 (PST)
From: Douglas Marsh <dmarsh@spscc.ctc.edu>
Subject: Re: [PORTS] cygwin32 port??

BTW I did DL 6.3.. ( also appologize, I didn't mean to spell you name
wrong.. Hermit...)

Interesting thing.. It was slow via direct (from your ftp site to PC via
PPP modem connection... I telneted into work Unix-HPUX machine and ftp'ed
there... fast and then DL from there to home... much faster ...!)

From scrappy
Date: Wed, 28 Jan 1998 23:57:47 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Wed, 28 Jan 1998, Douglas Marsh wrote:

linking ./backend/port/tas/i386_solaris.s to backend/port/tas.s
linking ./backend/port/dynloader/cygwin32.c to backend/port/dynloader.c
configure: error: ./backend/port/dynloader/cygwin32.c: File not found
/d/home/user/work/postgresql/pgsql/src #

(i've done this twice.. the first time I ran and pick the linux
template.. the second time I picked generic... I will continue to "hack"
at it...)....

Is there something I should know about the above directory!?
./backend/port/dynloader/cygwin32.c or do you have a suggested here!? Do
you want the cache file or any other files generated by ./configure ??
From here, you are pretty much on your own :) You have to build
up the various "support" files for the cygwin32 system..

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Wed, 28 Jan 1998 20:13:09 -0800 (PST)
From: Douglas Marsh <dmarsh@spscc.ctc.edu>
Subject: Re: [PORTS] cygwin32 port??
From here, you are pretty much on your own :) You have to build
up the various "support" files for the cygwin32 system..


Ah... Hmm.. Now I guess I have to figure out how cygnus support linking
(in this case dynamic linking)... I'm into programming, but whew... I
will attempt to copy the files from linux.* to cygnus.* at a first
start.. (sounds like a good idea?!) then go after the errors produced by
the compiler... perhaps report and sumbit this info to here and to the
somebody over at cygnus.. I got a message from what sounded like a sales
person over there when I was in some fashion praising cygnus's attempt at
this rather envolved port for GNU (which provided a lot of programming
support taken from the Unix-world) ...

I will report here successes and failures and probably ask a bunch of
questions about particular routines...

thanks in advance!!!...

- --Doug!

From scrappy
Date: Wed, 28 Jan 1998 23:26:37 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] cygwin32 port??

Have you any knowledge of a good port of postgresql to work under
cygwin32 (Cygnus's port of GNU C/C++ and bunch of Unix-like support
tools, bash/grep/tee/flex/tcl/awk/etc...)???

I am interested in an attempting! Spoke with the Mermit Hacket
(scrappy@hub.org) and he suggest that I mail this question to you!. He (I
guess he did) also updated the make files to recongnize the cygnus
system.. I may be wrong maybe someone eelse did that. I plan to (after I
send this message off) DL the lattest 6.3 version and install the src
files and attempt a ./configure... thanks (in advanced) much for any help
that you might be able to throw my way...
Recommend posting to the questions group looking for people who have
attempted it. Them may be able to help. Make the subject clear so
people who know something will respond.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Wed, 28 Jan 1998 23:34:31 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] cygwin32 port??
Ah... Hmm.. Now I guess I have to figure out how cygnus support linking
(in this case dynamic linking)... I'm into programming, but whew... I
will attempt to copy the files from linux.* to cygnus.* at a first
start.. (sounds like a good idea?!) then go after the errors produced by
the compiler... perhaps report and sumbit this info to here and to the
somebody over at cygnus.. I got a message from what sounded like a sales
person over there when I was in some fashion praising cygnus's attempt at
this rather envolved port for GNU (which provided a lot of programming
support taken from the Unix-world) ...

I will report here successes and failures and probably ask a bunch of
questions about particular routines...
You may be able to get a personal tech. assistant on this when you tell
them what your are doing, and that it is PostgreSQL and 250k lines of
database engine code.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Wed, 28 Jan 1998 21:32:47 -0800 (PST)
From: Douglas Marsh <dmarsh@spscc.ctc.edu>
Subject: [none]

Is this a listserv??
I try to send a message to listserv@postgresql.org and subscribe to what
I believe to be a list (pgsql-ports)... Can anybody give me information.
Please make sure you don't respond just to the list as I will not get a
response back!...

- --Doug

From scrappy
Date: Thu, 29 Jan 1998 10:53:02 +0200
From: "Alexandr V. Goncharuk" <sasha@eurocom.odtel.net>
Subject: (no subject)

unsubscribe

From scrappy
Date: Thu, 29 Jan 1998 11:34:07 GMT
From: Andrew Martin <martin@biochemistry.ucl.ac.uk>
Subject: Re: [PORTS] IRIX n32/64 Failure
============================================================================

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



Your name : Ivan Cornell
Your email address : ivan.cornell@framestore.co.uk


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

Operating System (example: Linux 2.0.26 ELF) : IRIX 6.4

PostgreSQL version (example: PostgreSQL-6.2.1): PostgreSQL-6.2.1

Compiler used (example: gcc 2.7.2) : IRIX IDO 7.2 cc


Please enter a FULL description of your problem:
------------------------------------------------
Compiling postgresql as a n32 or 64 executable fails.
Many people run 6.1 and 6.2.1 very happily under IRIX 5.x.

There is a bug in IRIX 6.x ld and the workaround is fully explained
in the Irix-specific FAQ.

Are you sure this isn't the problem you are encountering???

Best wishes,


Andrew

- ----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

From scrappy
Date: Thu, 29 Jan 1998 07:03:37 -0500 (EST)
From: "Stan Brown" <stanb@awod.com>
Subject: HP 500 machines

I did some research and found out a little about the hP 500;s. Yhey are
indeed *realy* old machines. Odball architecture also. here is the
message I got about them:

In a message to me Stan Brown wrote:
I am familiar with S300/400 and 700/800 HP computers. I just ran across
a reference in some old code to an S500. Did such an anumal exist? If
so could someone tell me a little bit about it? Architecture
particulary.
The 500 (and 200) series were the first series of HP 9000 computers.
The 500 was a stack machine, all operations were done by pushing operands
onto the stack and then doing the calculations with the values on stack.
They had almost no processor registers (just IP and SP) and had a hardware
layout comparable to earlier 800's (the 8x5 series) in that you had I/O
slots at the back of the cabinet (half size slot), processor (they were
capable of using more then one cpu) and memory slots more to the front,
some cards, like the graphic adaptor used a full-size slot.
When we switched from the 500 to the 800 (550 to 825) we could take some
I/O cards with us, memory and cpu cards had to be traded in.
The 500 series only used HP-IB type of disk and other peripherals (like
a HP-IB printer, tape and cartridge units).
We started, in 1986 to 1988, with the 550 (later 2 of those) and in 1989
we traded them for two 825's, which were upgraded to 845's later.

For your information, the 200 series was Motorola based and a predecessor
of the later 300 series, it used the 68000 and 68010 cpu's.
We never had any, so cannot tell much more about it.
And there also was a (short-lived) 600 series, which was a stripped down,
server only version of the 800 (a bit like the Novell Netware server, it
was really only reachable over the network, as file server only, no real
login/user handling).
- --
\ / /
/#. # #- # /
## ## ## ## ##
# # ## ## ##
" " # ## ##
"." ". "./
TTTTTTTTTT UU UU Eef Hartman, System Administrator
TT UU UU
TT UU UU Delft University of Technology
TT UU UU Mathematics (Applied Analysis) dept.
TT UU UU Mekelweg 4, P.O. Box 5031
TT UU UU 2600 GA Delft, The Netherlands
TT UU UU e-mail : E.J.M.Hartman@math.tudelft.nl
TT UUUUUU fax : +31-15-278 7209


- --
Stan Brown stanb@netcom.com 770-996-6955
Factory Automation Systems
Atlanta Ga.
- --
Look, look, see Windows 95. Buy, lemmings, buy!
Pay no attention to that cliff ahead... Henry Spencer
(c) 1998 Stan Brown. Redistribution via the Microsoft Network is prohibited.

From scrappy
Date: Thu, 29 Jan 98 13:15:16 +0100
From: David Wetzel <dave@turbocat.de>
Subject: libpq on NT?

Hello!

Did someone port libpq to NT?

- ---
_ _
_(_)(_)_ David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse, D-16567 Muehlenbeck/Berlin, FRG,
_/ \_ Fax +49 33056 82835 NeXTmail dave@turbocat.de
(______) http://www.turbocat.de/
DEVELOPMENT * CONSULTING * ADMINISTRATION
WATCH OUT FOR TURBOFAX for OPENSTEP!

From scrappy
Date: Thu, 29 Jan 1998 07:59:13 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Wed, 28 Jan 1998, Bruce Momjian wrote:



Have you any knowledge of a good port of postgresql to work under
cygwin32 (Cygnus's port of GNU C/C++ and bunch of Unix-like support
tools, bash/grep/tee/flex/tcl/awk/etc...)???

I am interested in an attempting! Spoke with the Mermit Hacket
(scrappy@hub.org) and he suggest that I mail this question to you!. He (I
guess he did) also updated the make files to recongnize the cygnus
system.. I may be wrong maybe someone eelse did that. I plan to (after I
send this message off) DL the lattest 6.3 version and install the src
files and attempt a ./configure... thanks (in advanced) much for any help
that you might be able to throw my way...
Recommend posting to the questions group looking for people who have
attempted it. Them may be able to help. Make the subject clear so
people who know something will respond.
Oh, so its *you* getting ppl to post inappropriate postings to the
questions group??? *sigh* And all this time I thought it was the newbies
doing it on their own :(

Do not post porting issues to the questions newsgroup...it is not
what it is meant for :(

From scrappy
Date: Thu, 29 Jan 1998 08:36:49 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] cygwin32 port??
On Wed, 28 Jan 1998, Bruce Momjian wrote:



Have you any knowledge of a good port of postgresql to work under
cygwin32 (Cygnus's port of GNU C/C++ and bunch of Unix-like support
tools, bash/grep/tee/flex/tcl/awk/etc...)???

I am interested in an attempting! Spoke with the Mermit Hacket
(scrappy@hub.org) and he suggest that I mail this question to you!. He (I
guess he did) also updated the make files to recongnize the cygnus
system.. I may be wrong maybe someone eelse did that. I plan to (after I
send this message off) DL the lattest 6.3 version and install the src
files and attempt a ./configure... thanks (in advanced) much for any help
that you might be able to throw my way...
Recommend posting to the questions group looking for people who have
attempted it. Them may be able to help. Make the subject clear so
people who know something will respond.
Oh, so its *you* getting ppl to post inappropriate postings to the
questions group??? *sigh* And all this time I thought it was the newbies
doing it on their own :(

Do not post porting issues to the questions newsgroup...it is not
what it is meant for :(
I am caught. Hands up.

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Thu, 29 Jan 1998 09:04:39 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Thu, 29 Jan 1998, Bruce Momjian wrote:

On Wed, 28 Jan 1998, Bruce Momjian wrote:



Have you any knowledge of a good port of postgresql to work under
cygwin32 (Cygnus's port of GNU C/C++ and bunch of Unix-like support
tools, bash/grep/tee/flex/tcl/awk/etc...)???

I am interested in an attempting! Spoke with the Mermit Hacket
(scrappy@hub.org) and he suggest that I mail this question to you!. He (I
guess he did) also updated the make files to recongnize the cygnus
system.. I may be wrong maybe someone eelse did that. I plan to (after I
send this message off) DL the lattest 6.3 version and install the src
files and attempt a ./configure... thanks (in advanced) much for any help
that you might be able to throw my way...
Recommend posting to the questions group looking for people who have
attempted it. Them may be able to help. Make the subject clear so
people who know something will respond.
Oh, so its *you* getting ppl to post inappropriate postings to the
questions group??? *sigh* And all this time I thought it was the newbies
doing it on their own :(

Do not post porting issues to the questions newsgroup...it is not
what it is meant for :(
I am caught. Hands up.
*sigh* *shakes finger at Bruce* Do I have to make all these
mailing lists moderated, with you as moderator? *grin*

From scrappy
Date: Thu, 29 Jan 1998 10:06:08 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: backend dumps core during simple query

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


Your name : David Mansfield
Your email address : david@cobite.com

Category : runtime: back-end
Severity : critical

Summary: backend dumps core during simple query

System Configuration
- --------------------
Operating System : RedHat 4.2, pentium II

PostgreSQL version : 6.2.1

Compiler used : gcc 2.7.2

Hardware:
- ---------
Linux host 2.0.30 #1 Tue Jul 15 18:21:55 EDT 1997 i686 unknown

Versions of other tools:
- ------------------------
stock redhat4.2 tools

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

Problem Description:
- --------------------
query: select name from names group by name;
table: create table names ( name text );
index: create index names01 on names(name);
results:
FATAL: unrecognized data from the backend. It probably dumped core.
FATAL: unrecognized data from the backend. It probably dumped core.

The backend is dead. Exit psql and restart.

The table contains about 8500 names in the format
'LASTNAME, FIRSTNAME'. That's it...

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

Test Case:
- ----------
See description.


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

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


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

From scrappy
Date: Thu, 29 Jan 1998 11:44:28 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: misc regress test fails, no copy_seq under user_relns

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


Your name : michael lewis
Your email address : mlweis@cs5.dasd.honeywell.com

Category : install: other
Severity : serious

Summary: misc regress test fails, no copy_seq under user_relns

System Configuration
- --------------------
Operating System : Linux 2.0.29 ELF i586 Debian 1.3.1

PostgreSQL version : 6.2.1

Compiler used : gcc 2.7.2.1

Hardware:
- ---------
Pentium 166, 32Meg ram, 1GIG hd

Versions of other tools:
- ------------------------
gmake 3.75
flex 2.5.4
ld 2.8.1

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

Problem Description:
- --------------------
While installing 6.2.1, I ran the regression tests. The misc was
the only section that failed. Running diff, found that copy_seq did not
list in the last test of the the section (SELECT user_relns()).
This also results in (65 rows) instead of (66 rows) at the end of
the test. These are the only failures I could find.

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

Test Case:
- ----------
I ran the tests again (after a make clean) and got the same
results.

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

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


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

From scrappy
Date: Thu, 29 Jan 1998 16:40:50 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Subject: Re: [PORTS] cygwin32 port??
Oh, so its *you* getting ppl to post inappropriate postings to the
questions group??? *sigh* And all this time I thought it was the newbies
doing it on their own :(

Do not post porting issues to the questions newsgroup...it is not
what it is meant for :(
I am caught. Hands up.
*sigh* *shakes finger at Bruce* Do I have to make all these
mailing lists moderated, with you as moderator? *grin*
Well, I guess I would have done the same as Bruce, since the issue in this case was
trying to survey as many people as possible, hoping to catch the person who had done
this before but who was not responding to the initial messages on the correct list.

It's probably OK sometimes, right? Right?? (Guess which answer I'm hoping for :)

- Tom

From scrappy
Date: Thu, 29 Jan 1998 12:06:00 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Thu, 29 Jan 1998, Thomas G. Lockhart wrote:

Oh, so its *you* getting ppl to post inappropriate postings to the
questions group??? *sigh* And all this time I thought it was the newbies
doing it on their own :(

Do not post porting issues to the questions newsgroup...it is not
what it is meant for :(
I am caught. Hands up.
*sigh* *shakes finger at Bruce* Do I have to make all these
mailing lists moderated, with you as moderator? *grin*
Well, I guess I would have done the same as Bruce, since the issue in
this case was trying to survey as many people as possible, hoping to
catch the person who had done this before but who was not responding to
the initial messages on the correct list.

It's probably OK sometimes, right? Right?? (Guess which answer I'm
hoping for :)
Geez, these subtle hints...don't know if I can figure this one out
:) If everyone actually did a concerted effort to move discussions *from*
pgsql-questions to where they belonged, then yes, sometimes its OK...but
nobody does. Like, its too much hassle to change '-questions' to
'-interfaces' and stuff like that.

From scrappy
Date: Thu, 29 Jan 1998 14:03:10 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] cygwin32 port??
It's probably OK sometimes, right? Right?? (Guess which answer I'm
hoping for :)
Geez, these subtle hints...don't know if I can figure this one out
:) If everyone actually did a concerted effort to move discussions *from*
pgsql-questions to where they belonged, then yes, sometimes its OK...but
nobody does. Like, its too much hassle to change '-questions' to
'-interfaces' and stuff like that.
We have an interfaces list? :-)

- --
Bruce Momjian
maillist@candle.pha.pa.us

From scrappy
Date: Thu, 29 Jan 1998 15:08:04 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Thu, 29 Jan 1998, Bruce Momjian wrote:

It's probably OK sometimes, right? Right?? (Guess which answer I'm
hoping for :)
Geez, these subtle hints...don't know if I can figure this one out
:) If everyone actually did a concerted effort to move discussions *from*
pgsql-questions to where they belonged, then yes, sometimes its OK...but
nobody does. Like, its too much hassle to change '-questions' to
'-interfaces' and stuff like that.
We have an interfaces list? :-)
*bang head against a wall* *sigh*

From scrappy
Date: Thu, 29 Jan 1998 13:59:23 -0800 (PST)
From: Douglas Marsh <dmarsh@spscc.ctc.edu>
Subject: Sorry about posting here...

Where can I post question and updates to others about my attempts???

I am not seriously attacking this project (porting PostgreSQL 6.3 to
cygwin32)...

BTW: I have be able to get the ./configure to make (GNU)Makefiles and
have begun the process of finding the right headers and directory
paths... (I've already completely comiled the first few .o files) I
stopped once at the inter process communication that I believe is
temporary solved... Now I am stuck with the Socket stuff (Socket_un)..
The Socket support I believe to be fairly complete but I am looking
(attempting to find some) source code and other header files...

Sorry again... I would like to have a reasonable contact person (from the
postgres folks) a news group or a single person (I attempt the Hermit
Hacker because of the information provided via the ./configure ).

Thanks in advance!!

- --Doug

From scrappy
Date: Thu, 29 Jan 1998 14:58:15 -0800
From: Gene Hightower <gene@west.enterworks.com>
Subject: Successful build of PostgreSQL 6.2.1 on Solaris 2.6

- The version of PostgreSQL (v6.2.1, 6.1.1, beta 970703, etc.).

6.2.1

- Your operating system (i.e. RedHat v4.0 Linux v2.0.26).
- Your hardware (SPARC, i486, etc.).

SunOS 5.6 for sparc
gcc version 2.8.0

- Did you compile, install and run the regression tests cleanly?

It compiled and installed without problems. The regression tests that
it failed are:

int2, int4, oidint2 and oidint4 failed with slightly different error
messages ("Math result not representable" vs. "Result too large")

float8 failed with slight precision differences

geometry failed with slight precision differences

tinterval failed with what appeared to be a difference in what date
"-infinity" was (sometime in 1990 vs. sometime in 1949)

I hope this information is helpful.

-- Gene

From scrappy
Date: Thu, 29 Jan 1998 22:04:49 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] cygwin32 port??
On Wed, 28 Jan 1998, Douglas Marsh wrote:



BTW I did DL 6.3.. ( also appologize, I didn't mean to spell you name
wrong.. Hermit...)

Interesting thing.. It was slow via direct (from your ftp site to PC via
PPP modem connection... I telneted into work Unix-HPUX machine and ftp'ed
there... fast and then DL from there to home... much faster ...!)
That's normal...:)
>

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 29 Jan 1998 22:07:31 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: Sorry about posting here...
On Thu, 29 Jan 1998, Douglas Marsh wrote:


Where can I post question and updates to others about my attempts???
This is the perfect place...we'll try and help to the best of our
abilities, but please remember to document as much as possible so that
hopefully we can include changes as required so that its easier for the
next person? :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From scrappy
Date: Thu, 29 Jan 1998 20:26:32 -0800 (PST)
From: Simon Shapiro <shimon@simon-shapiro.org>
Subject: Re: your mail

I am redirecting to the database list, which is more appropriate. I think.
On 29-Jan-98 The Hermit Hacker wrote:
On Thu, 29 Jan 1998, Simon Shapiro wrote:

I am on shaky ground here, so be kind to me:

I am trying to get a very new PostgreSQL snapshot to work.
One of the things it does is create a UNIX Socket in /tmp.
It uses a template to create the ``filename'':

#define UNIXSOCK_PATH(sun,port) \
(sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)) + \
sizeof ((sun).sun_family))

This seems to work OK (I traced it in the RDBMS code), up to the bind
syscall. The port is 5432, and the socket gets created as:

srwx------ 1 pgsql bin 0 Jan 27 16:18 /tmp/.s.PGSQL.543

The bind(2) call is:

Just curious, but I'm running the snapshot on my 3.0-CURRENT
machine and I can run the full regression tests without a problem...what
sort of problem are you experiencing?
Cannot connect. It looks like either the pg_hba.conf file is incorrect
(including the one which works in 6.2.1), or that the sockets cannot be
opened. While digging, I see that the filename representing the Unix
socket is wrong (the last digit gets truncated).

I need to try today's snapshot. Maybe the problem is gone.

- ----------


Sincerely Yours,

Simon Shapiro
Shimon@Simon-Shapiro.ORG Voice: 503.799.2313

From scrappy
Date: Fri, 30 Jan 1998 05:09:28 -0800
From: "Kevin M. Kilbride" <chandra@ssl.org>
Subject: Compilation report

VERSION: 6.2.1 with Debian patch level 9 applied
OS: Debian Linux, 2.1.82 kernel
HARDWARE: AMD K6/200 in FIC PA-2007 motherboard; 64MB SDRAM

Compiled successfully with PGCC-1.0.1 with "-O6 -mcpu=pentiumpro -pipe"
flags. Two source files would not compile with -O6 flag; were manually
compiled with -O2 flag instead---problem undoubtedly lies with PGCC.

Regression test completed "successfully," with failures on tests with
floating point parameters (as explained in the INSTALL file). Time to
completion was 4m36s with 0m2.25s user and 0m2.07s system CPU times. System
load at completion was about 0.50 (the Fujitsu 1.7GB IDE drive in this
machine is an obvious weak link). The kernel was also compiled with PGCC at
- -O6 optimization level.

Some of the diffs indicated rather significant floating point differences,
but I suppose this can be attributed to AMD vs. Intel peculiarities.

Conclusion: Postgresql compiles successfully on Intel hardware with the
02JAN98 distribution of the Pentium Compiler Group's "GCC" compiler and
appears to benefit noticeably from the optimizations offered by that
compiler, giving every indication that it is disk-bound on this system even
at a 4.5-minute benchmark time.


Kevin M. Kilbride
Sapient Systems Laboratories
259-B Burton Mesa Blvd.
Lompoc, CA 93436-1471
chandra@sapient.lompoc.ca.us
chandra@impulse.net
From scrappy
Date: Fri, 30 Jan 1998 13:44:05 -0500
From: Bobby Hitt <bobhitt@russianstory.com>
Subject: postgres regression tests fail

Tried running the regression tests, ALL tests failed. I saw the error
message "unable to delete regression database" on startup. As an experiment
I commented out the line, and createdb never failed, even though I ran it
several times. With an existing regression database, shouldn't it have failed?

The test platform is a Pentium 200, 32MB RAM running Solaris 2.5 with
driver update 11 patches. I looked at the result/*.out files, and they all
contain the following:

Connection to database 'regression' failed.
FATAL 1:Database regression does not exist in pg_database.

If I type "createdb regression", I don't get an error. So where is the
database getting created, and why doesn't destroydb regression work?

I have previously installed postgres 6.0 on a Linux 2.0.31 platform, and
it's regression tessing is totally different. And it works.

Any ideas?

Bobby Hitt (bobhitt@russianstory.com)
Northern Virginia Information Services
14454 Lee Hwy, #259
Gainesville, VA 20155
(703) 754-8772

From scrappy
Date: Sat, 31 Jan 1998 03:41:08 -0500
From: "Billy G. Allie" <Bill.Allie@mug.org>
Subject: Patches to the UNIVEL port to fit the new porting model.

This is a multipart MIME message.

- --==_Exmh_-14831215960
Content-Type: text/plain; charset=us-ascii

The following patches will bring the UNIVEL port in line with the new porting
model used in postgreSQL 6.3

NOTE: The src/backend/port/univel directory can be deleted.



- --==_Exmh_-14831215960
Content-Type: application/x-patch ; name="univel.patch"
Content-Description: univel.patch
Content-Disposition: attachment; filename="univel.patch"

*** src/backend/port/dynloader/univel.c.orig Fri Jan 30 17:24:36 1998
- --- src/backend/port/dynloader/univel.c Fri Jan 30 17:21:58 1998
***************
*** 0 ****
- --- 1,4 ----
+ /* Dummy file used for nothing at this point
+ *
+ * see univel.h
+ */
*** src/backend/port/dynloader/univel.h.orig Fri Jan 30 17:24:36 1998
- --- src/backend/port/dynloader/univel.h Fri Jan 30 17:21:58 1998
***************
*** 0 ****
- --- 1,34 ----
+ /*-------------------------------------------------------------------------
+ *
+ * port-protos.h--
+ * port-specific prototypes for Intel x86/UNIXWARE
+ *
+ *
+ * Copyright (c) 1994, Regents of the University of California
+ *
+ * port-protos.h,v 1.2 1995/03/17 06:40:18 andrew Exp
+ *
+ *-------------------------------------------------------------------------
+ */
+ #ifndef PORT_PROTOS_H
+ #define PORT_PROTOS_H
+
+ #include <dlfcn.h>
+ #include "fmgr.h" /* for func_ptr */
+ #include "utils/dynamic_loader.h"
+
+ /* dynloader.c */
+ /*
+ * Dynamic Loader on Intel x86/Intel SVR4.
+ *
+ * this dynamic loader uses the system dynamic loading interface for shared
+ * libraries (ie. dlopen/dlsym/dlclose). The user must specify a shared
+ * library as the file to be dynamically loaded.
+ *
+ */
+ #define pg_dlopen(f) dlopen(f,RTLD_LAZY)
+ #define pg_dlsym dlsym
+ #define pg_dlclose dlclose
+ #define pg_dlerror dlerror
+
+ #endif /* PORT_PROTOS_H */
*** src/include/parser/parse_node.h.orig Fri Jan 30 19:04:25 1998
- --- src/include/parser/parse_node.h Fri Jan 30 19:04:58 1998
***************
*** 28,34 ****
/* state information used during parse analysis */
typedef struct ParseState
{
- - struct ParseState;
int p_last_resno;
List *p_rtable;
List *p_insert_columns;
- --- 28,33 ----
*** src/include/port/univel.h.orig Sat Jan 31 01:59:49 1998
- --- src/include/port/univel.h Sat Jan 31 02:02:12 1998
***************
*** 11,16 ****
- --- 11,21 ----
\***************************************/
typedef unsigned char slock_t;

+ /***************************************************************\
+ | strcasecmp() is in c89, but is not in any include file :-( |
+ \***************************************************************/
+ int strcasecmp(char *, char *);
+
#ifndef BIG_ENDIAN
#define BIG_ENDIAN 4321
#endif
*** src/template/univel.orig Fri Jan 30 17:21:28 1998
- --- src/template/univel Sat Jan 31 01:12:42 1998
***************
*** 1,10 ****
AROPT:crs
! CFLAGS:-I$(SRCDIR)/backend/port/univel -Xa -v -DHAVE_RUSAGE -O -K i486,host,inline,loop_unroll -Dsvr4
SHARED_LIB:-K PIC
SRCH_INC:
SRCH_LIB:
USE_LOCALE:no
DLSUFFIX:.so
YFLAGS:-d
- - YACC:yacc
CC:cc
- --- 1,11 ----
AROPT:crs
! CFLAGS:-Xa -v -O -K i486,host,inline,loop_unroll -Dsvr4
SHARED_LIB:-K PIC
SRCH_INC:
SRCH_LIB:
USE_LOCALE:no
DLSUFFIX:.so
+ YACC=/usr/ccs/bin/yacc
YFLAGS:-d
CC:cc
+ LIBS:-lc89
*** src/configure.orig Fri Jan 30 17:20:40 1998
- --- src/configure Fri Jan 30 17:21:58 1998
***************
*** 695,700 ****
- --- 695,701 ----
YACC=`grep '^YACC:' $TEMPLATE | awk -F: '{print $2}'`
YFLAGS=`grep '^YFLAGS:' $TEMPLATE | awk -F: '{print $2}'`
CC=`grep '^CC:' $TEMPLATE | awk -F: '{print $2}'`
+ LIBS=`grep '^LIBS:' $TEMPLATE | awk -F: '{print $2}'`


echo "**************************************************************"
*** src/configure.in.orig Fri Jan 30 17:20:52 1998
- --- src/configure.in Fri Jan 30 17:23:42 1998
***************
*** 133,138 ****
- --- 133,139 ----
YACC=`grep '^YACC:' $TEMPLATE | awk -F: '{print $2}'`
YFLAGS=`grep '^YFLAGS:' $TEMPLATE | awk -F: '{print $2}'`
CC=`grep '^CC:' $TEMPLATE | awk -F: '{print $2}'`
+ LIBS=`grep '^LIBS:' $TEMPLATE | awk -F: '{print $2}'`


dnl We now need to check for additional directories (include

- --==_Exmh_-14831215960
Content-Type: text/plain; charset=us-ascii

____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
/| | 7436 Hartwell | Compuserve: 76337,2061
-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
/ |LLIE | (313) 582-1540 |
- --==_Exmh_-14831215960--

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedJan 1, '98 at 1:54p
activeJan 1, '98 at 1:54p
posts1
users1
websitepostgresql.org
irc#postgresql

1 user in discussion

Ryan Kirkpatrick: 1 post

People

Translate

site design / logo © 2022 Grokbase