Unprivileged user wrote:

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

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

Your name : Jeff Gerber
Your email address : jgerber@sitta.uwstout.edu

Category : unknown
Severity : critical

Summary: "non-present SYSVSHM"
(...)
Why is postgres looking for System V on a FreeBSD 2.2.5 system?
Is looking for SYSV IPC support in FreeBSD. You must enable this in
kernel.

Perhaps the INSTALL file or a system-specific FAQ should state this
clearly, as I see that this is really a F.A.Q.

C. Amengual
Healthnet SL
Barcelona, Spain

From scrappy
Date: Sat, 01 Nov 1997 13:35:46 +1000
From: Scott McClintock <scott@mu.com.au>
Subject: Re: [PORTS] Postgres in SCO...

Miguel Eduardo Ceniceros Castro wrote:
Dear Mr. Laufer,

I am a developer in Mexico exploring the PostgreSQL 6.2.1 in SCO
platform, I use your documentation for compile it...
Now, i have this problem:
When I use psql with simple comands "select * from weather" it succeds,
but if I try something like "select * from pg_user" or the createuser
command it sends a message:
PQexec(): Request was sent to backend but backend closed the channel
before responding. This probably means the backend terminated abnormally
before or while processing the request.

I am doing all this as postgres user, and I have my PGLIB and PGDATA
variables okay.

Any suggestion or help...?
I have found much the same thing. It seems that anything that queries
data dictionary type tables seems to cause the backend to core dump.
Very complex queries do also but I have found that things seem ok with
just simple queries. I loaded up a table with Australian place names
and postal codes (about 14,000 records) and had no trouble indexing and
querying. Try a "\d table-name" and it crashes.

I'm rather occupied with some other work at the moment so haven't had
time to investigate further but might be able to in a few weeks time.
If anybody else has any thoughts on these problems, I'd be interested
too. I have compiled postgresql to both COFF and ELF and had the same
results.

cheers

Scott.
- --
========================================================================
Scott McClintock EMail: scott@mu.com.au
MU Systems Pty Ltd Phone: +61 7 3351 6677
Brisbane Australia
- ------------------------------------------------------------------------
Authorised SCO Reseller C & Informix Development & Support for SCO
========================================================================

From scrappy
Date: Sat, 01 Nov 1997 18:03:11 -0600
From: Scott Bell <scott@computer.org>
Subject: Subscribe

Subscribe

From scrappy
Date: Mon, 3 Nov 1997 15:52:57 +0100 (CET)
From: Uwe Thormann <uwe@thormann.han.de>
Subject: [PORTS] postgreSQL6.2 Linux2.0.30

Hi,

I have Linux2.0.30 by SuSE5.0, gcc2.7.2.1
after make all while installation of PostgreSQL there is in make.log:

[...]
make -C psql all
make[2]: Entering directory `/usr/src/pgsql/postgresql-6.2/src/bin/psql'
make -C ../../interfaces/libpq libpq.a
make[3]: Entering directory `/usr/src/pgsql/postgresql-6.2/src/interfaces/libpq'
make[3]: `libpq.a' is up to date.
make[3]: Leaving directory `/usr/src/pgsql/postgresql-6.2/src/interfaces/libpq'
gcc -I../../include -I/usr/include/ncurses -I/usr/include/readline -O2 -Wall -Wmissing-prototypes -Dlinux -I../../interfaces/libpq -c psql.c -o psql.o
gcc -I../../include -I/usr/include/ncurses -I/usr/include/readline -O2 -Wall -Wmissing-prototypes -Dlinux -I../../interfaces/libpq -c stringutils.c -o stringutils.o
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+0x95b): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `update_line':
display.o(.text+0xe5a): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `_rl_move_cursor_relative':
display.o(.text+0x1106): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `_rl_move_vert':
display.o(.text+0x11d5): undefined reference to `tputs'
display.o(.text+0x1212): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o)(.text+0x160c): more undefined references to `tputs' follow
/usr/lib/libreadline.a(display.o): In function `insert_some_chars':
display.o(.text+0x16b2): undefined reference to `tgoto'
display.o(.text+0x16bf): undefined reference to `tputs'
display.o(.text+0x16e3): undefined reference to `tputs'
display.o(.text+0x170e): undefined reference to `tputs'
display.o(.text+0x173c): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `delete_chars':
display.o(.text+0x176d): undefined reference to `tgoto'
display.o(.text+0x1779): undefined reference to `tputs'
display.o(.text+0x179e): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `cr':
display.o(.text+0x18b5): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o): In function `_rl_redisplay_after_sigwinch':
display.o(.text+0x18de): undefined reference to `tputs'
display.o(.text+0x1901): undefined reference to `tputs'
/usr/lib/libreadline.a(display.o)(.text+0x1925): more undefined references to `tputs' follow
/usr/lib/libreadline.a(terminal.o): In function `_rl_get_screen_size':
terminal.o(.text+0x81): undefined reference to `tgetnum'
terminal.o(.text+0xd7): undefined reference to `tgetnum'
/usr/lib/libreadline.a(terminal.o): In function `get_term_capabilities':
terminal.o(.text+0x19b): undefined reference to `tgetstr'
/usr/lib/libreadline.a(terminal.o): In function `_rl_init_terminal_io':
terminal.o(.text+0x24f): undefined reference to `tgetent'
terminal.o(.text+0x334): undefined reference to `PC'
terminal.o(.text+0x33e): undefined reference to `BC'
terminal.o(.text+0x348): undefined reference to `UP'
terminal.o(.text+0x396): undefined reference to `tgetflag'
terminal.o(.text+0x3a7): undefined reference to `tgetflag'
terminal.o(.text+0x3f7): undefined reference to `tgetflag'
terminal.o(.text+0x408): undefined reference to `tgetflag'
/usr/lib/libreadline.a(terminal.o): In function `_rl_backspace':
terminal.o(.text+0x60a): undefined reference to `tputs'
/usr/lib/libreadline.a(terminal.o): In function `ding':
terminal.o(.text+0x6ab): undefined reference to `tputs'
/usr/lib/libreadline.a(terminal.o): In function `_rl_enable_meta_key':
terminal.o(.text+0x732): undefined reference to `tputs'
/usr/lib/libreadline.a(terminal.o): In function `_rl_control_keypad':
terminal.o(.text+0x757): undefined reference to `tputs'
terminal.o(.text+0x772): undefined reference to `tputs'
make[2]: *** [psql] Error 1
make[2]: Leaving directory `/usr/src/pgsql/postgresql-6.2/src/bin/psql'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/pgsql/postgresql-6.2/src/bin'
make: *** [all] Error 2
[...]

what the matter?

Uwe Thormann
Steinstr. 8a
30559 Hannover

From scrappy
Date: Mon, 3 Nov 1997 14:48:51 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Tutorial - advanced doesn't work

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


Your name : Ralf Mattes
Your email address : mattes@mhs.uni-freiburg.de

Category : install: other
Severity : non-critical

Summary: Tutorial - advanced doesn't work

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

PostgreSQL version : 6.2

Compiler used : gcc 2.7.2.1

Hardware:
- ---------
Pentium, 64M Ram
uname -a: Linux park133.dcpa.org 2.0.27

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

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

Problem Description:
- --------------------
I was not able to run the file advanced.source with
'psql -s'. Several parser errors.

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

Test Case:
- ----------
run: 'psql -s'
in psql type '\i advanced.source' [return]

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

Solution:
- ---------
It seems that psql expects a semicolon ';' after every
SQL-expression, otherwise the parser creates an error.
Can be easily fixed: Just append a semicolon after every
SQL-statement.

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

From scrappy
Date: Mon, 3 Nov 1997 18:03:37 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [QUESTIONS] Porting to HPUX 10.20
Has anyone been successful at porting 6.2 or later versions to hpux
10.20.

If you have, please give me the latest on how to do it. So far I have
had no luck.
6.2 should work. I believe is has been tested on 10.10 and 10.20. I am
not sure what compiler was used.


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

From scrappy
Date: Tue, 04 Nov 1997 03:22:40 +0100
From: Tamas Laufer <lt660@ipisun.jpte.hu>
Subject: Re: [PORTS] Postgres in SCO...

Dear Miguel,

Sorry for late reply, I apologize to you.

You wrote:
When I use psql with simple comands "select * from weather" it
succeds,
but if I try something like "select * from pg_user" or the createuser
command it sends a message:
PQexec(): Request was sent to backend but backend closed the channel
before responding. This probably means the backend terminated abnormally
before or while processing the request.

I am doing all this as postgres user, and I have my PGLIB and PGDATA
variables okay.
I tried out the "select * from pg_user" and I got:

usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd
- --------+--------+-----------+--------+--------+---------
postgres| 204|t |t |t |t
(1 row)

The "createuser" (from sh) works correctly too.


I think there is a missing modification at your site but I'm not sure of
it.
In the file "./src/backend/tcop/postgres.c", the SIGHUP signal-handler
function must be modified to

void
handle_warn(SIGNAL_ARGS)
{
#ifdef SCO
pqsignal(SIGHUP,handle_warn); /* reinit in handler for SCO */
#endif
siglongjmp(Warn_restart, 1);
}


Note: I have an exported "USER=<postgres superuser's username> in the
".profile" of postgres superuser.


Best regards,
Tamas

_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

From scrappy
Date: Tue, 04 Nov 1997 09:25:51 +0100
From: "Francisco =?iso-8859-1?Q?Jos=E9?= Esteban =?iso-8859-1?Q?Risue=F1o?=" <Franciscojose.Esteban@dgp.mir.es>
Subject: bug report on Solaris x86 2.5.1

Este es un mensaje multipartes en formato MIME.
- --------------7413146ABC6A87B21566AD97
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I didn't complete the form in my last message; so, I repeat it:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

POSTGRESQL BUG REPORT TEMPLATE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Your name : Francisco Jos=E9 Esteban
Your email address : franciscojose.esteban@dgp.mir.es

System Configuration
- ---------------------
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Solaris x86 2.5.1
PostgreSQL version (example: PostgreSQL-6.2.1): PostgreSQL-6.2.1
Compiler used (example: gcc 2.7.2) : gcc 2.7.2.1
Other tools: flex 2.5.4 gmake 3.63

Please enter a FULL description of your problem:
- ------------------------------------------------
I've got the following errors during my compilation:

1.- heapvalid.c: fmgr.h not found. Fixed copying src/backend/fmgr.h to
src/include

2.- parser.c: port/inet_aton.h not found. Fixed copying
src/backend/port/inet_aton.h to src/include

3.- date.c: INT_MAX undefined. Fixed touching s_lock.h in order to
define manually the values writen for i386_solaris.

4.- linking postgres: undefined my_isinf. Fixed touching float.c in
order to define manually the values writen for i386_solaris.

5.- linking libpq.so.1: many, many errors about external references not
relocatables. Fixed deleting -Z text on line 48 of the Makefile.

6.- I'm rather surprised about the fact that in every compilation the
src/backend/port/sparc_solaris was included, instead of
/src/backend/port/i386_solaris, which contains the same files, but with
different contents.

After this "via-crucis", I succesfully compiled the application. Theese
where the results of the regression test:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D running regression queries.=
=2E. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
boolean .. ok
char .. ok
char16 .. ok
char2 .. ok
char4 .. ok
char8 .. ok
text .. ok
int2 .. failed
int4 .. failed
oid .. ok
oidint2 .. failed
oidint4 .. failed
oidname .. ok
float4 .. ok
float8 .. failed
numerology .. ok
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
geometry .. failed
timespan .. ok
datetime .. ok
reltime .. ok
abstime .. failed
tinterval .. failed
horology .. failed
comments .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. ok
constraints .. failed
triggers .. failed c
opy .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_view .. ok
create_index .. ok
sanity_check .. ok e
rrors .. failed
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
aggregates .. ok
transactions .. ok
random .. failed
portals .. ok
misc .. failed
arrays .. ok
btree_index .. ok
select_views .. failed
alter_table .. ok
purge .. ok
portals_p2 .. ok

I' don't know if it's all right, but now I have the following problem:
when I make an insert width more than three columns (no mather what
columns they are) the insertion is right, but when I try to select the
fourth column, the backend generates a core and exits.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------

$ psql template1
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: ucci
template1=3D> create database test;
CREATE
template1=3D>\c test
connecting to new database: test
test=3D> create table prueba (a char(10),b char(10),c char(10) ,d
char(10));
CREATE
test=3D> insert into prueba values ('hola','hola','hola','hola');
INSERT 213617 1
test=3D> select * from prueba;
FATAL: unrecognized data from the backend. It probably dumped core.
FATAL: unrecognized data from the backend. It probably dumped core.


I get the same result inserting the row via the JDBC driver or inserting

less than four columns and then updating the row up to more than three
not-null values.


If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------
It seems that my compiler has some problem with #if defined(...) ||
defined(..)
Perhaps any necesary code not compiled?




- --
Saludos Cordiales,

______________________________________________________
Francisco Jos=E9 Esteban Risue=F1o
Jefe de Proyecto
=C1rea de Inform=E1tica - Direcci=F3n General de la Polic=EDa
tfno. (91) 890 22 11 fax. (91) 890 20 18
El Escorial (Madrid - Espa=F1a)
______________________________________________________


- --------------7413146ABC6A87B21566AD97
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Tarjeta de Francisco José Esteban Risueño
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Francisco José Esteban Risueño
n: Esteban Risueño;Francisco José
org: Dirección General de la Policía. Área de Informática
adr: Ctra. M-505 km. 5.5;;;El Escorial;Madrid;28280;España
email;internet: Franciscojose.Esteban@dgp.mir.es
title: Jefe de Proyecto
tel;work: (91) 890 22 11
tel;fax: (91) 890 20 18
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard


- --------------7413146ABC6A87B21566AD97--

From scrappy
Date: Wed, 05 Nov 1997 13:35:23 +0000
From: Dr Stephen Henson <shenson@bigfoot.com>
Subject: Problems compiling/running in SCO 3.2v5.0.2

Here is report of problems I've had getting PostgreSQL-6.2.1 running on
SCO 3.2v5.0.2. Does anyone know where I can get binaries for SCO?

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


Your name : Stephen N Henson
Your email address : shenson@bigfoot.com


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

Operating System (example: Linux 2.0.26 ELF) : SCO 3.2v5.0.2

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

Compiler used (example: gcc 2.7.2) : gcc 2.7.2


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

Several compilation problems (annoying but fairly minor). These are
probably due to my using the GNU C development system, described as "GNU
Development System (ver 95.4c)" instead of the commercial SCO one (which
I don't have).

1. System type not recognised by "configure", entered manually.
config.guess produces i486-pc-sco3.2v5.0.2 (this system was upgraded
from a 486 box).
2. cpp not found when running a few scripts (e.g. Gen_fmgrtab.sh),
modified to use gcc -E
3. nabstime.c not compiled due to undefined structure "tx". Needed to
add USE_POSIX_TIME to config.h
4. One of library builds failed due to lack of lorder/tsort: set
MK_NO_LORDER.
5. -K PIC not recognised as a compile option, changed to -fPIC
6. modified ld options in Makefile.port to build shared library properly
using options -G -b elf
7. standard install is in /etc and the options are different/broken.
Used install-sh.

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

Several regression tests failed (e.g. int2, int4). The reason seems to
be a crash/confusion of pg_atoi. E.g. int2.out reads:

QUERY: CREATE TABLE INT2_TBL(f1 int2);
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('0');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('1234');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-1234');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('34.5');
WARN:pg_atoi: error in "34.5": can't parse ".5"
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('32767');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('-32767');
QUERY: INSERT INTO INT2_TBL(f1) VALUES ('100000');
WARN:pg_atoi: error reading "100000": Result too large or too small
*QUERY: INSERT INTO INT2_TBL(f1) VALUES ('asdf');
PQexec() -- Request was sent to backend, but backend closed the channel
before responding. This probably means the backend terminated
abnormally before or while processing the request.
QUERY: SELECT '' AS five, INT2_TBL.*;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS four, i.* FROM INT2_TBL i WHERE i.f1 <> '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS four, i.* FROM INT2_TBL i WHERE i.f1 <> '0'::int4;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS one, i.* FROM INT2_TBL i WHERE i.f1 = '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS one, i.* FROM INT2_TBL i WHERE i.f1 = '0'::int4;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS two, i.* FROM INT2_TBL i WHERE i.f1 < '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS two, i.* FROM INT2_TBL i WHERE i.f1 < '0'::int4;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS three, i.* FROM INT2_TBL i WHERE i.f1 <= '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS three, i.* FROM INT2_TBL i WHERE i.f1 <= '0'::int4;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS two, i.* FROM INT2_TBL i WHERE i.f1 > '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS two, i.* FROM INT2_TBL i WHERE i.f1 > '0'::int4;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS three, i.* FROM INT2_TBL i WHERE i.f1 >= '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS three, i.* FROM INT2_TBL i WHERE i.f1 >= '0'::int4;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS one, i.* FROM INT2_TBL i WHERE (i.f1 % '2'::int2) =
'1'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS three, i.* FROM INT2_TBL i WHERE (i.f1 % '2'::int4)
= '0'::int2;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 * '2'::int2 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 * '2'::int4 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 + '2'::int2 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 + '2'::int4 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 - '2'::int2 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 - '2'::int4 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 / '2'::int2 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.
QUERY: SELECT '' AS five, i.f1, i.f1 / '2'::int4 AS x FROM INT2_TBL i;
PQexec() -- There is no connection to the backend.

I'm not sure what is causing this, but a check of pg_atoi at the point
marked by a '*' shows that the arguments to pg_atoi are corrupted: it
never receives "asdf". This suggests the previous call may be the
problem.

This does not crash postmaster it just seems to affect this one process
the next carries on until it fails in a similar manner.

The pattern is repeated in several tests: a few lines OK (other than
different error messages) followed by loss of connection. Eventually
"postmaster" crashes.


boolean .. ok
char .. ok
char16 .. ok
char2 .. ok
char4 .. ok
char8 .. ok
text .. ok
int2 .. failed
int4 .. failed
oid .. failed
oidint2 .. failed
oidint4 .. failed
oidname .. failed
float4 .. failed
float8 .. failed
numerology .. failed
point .. failed
lseg .. failed
box .. failed
path .. failed
polygon .. failed
circle .. failed
geometry .. failed
timespan .. failed
datetime .. failed
reltime .. failed
abstime .. failed
tinterval .. failed
horology .. failed
comments .. ok
create_function_1 .. ./regress.sh: sql/create_function_1.sql: cannot
open
diff: cannot stat expected/create_function_1.out: No such file or
directory (error 2)
ok
create_type .. failed
create_table .. ok
create_function_2 .. ./regress.sh: sql/create_function_2.sql: cannot
open
diff: cannot stat expected/create_function_2.out: No such file or
directory (error 2)
ok
constraints .. ./regress.sh: sql/constraints.sql: cannot open
diff: cannot stat expected/constraints.out: No such file or directory
(error 2)
ok
triggers .. failed
copy .. ./regress.sh: sql/copy.sql: cannot open
diff: cannot stat expected/copy.out: No such file or directory (error 2)
ok
create_misc .. failed
create_aggregate .. ok
create_operator .. failed
create_view .. failed
create_index .. ok
sanity_check .. failed
errors .. failed
select .. failed
select_into .. ok
select_distinct .. failed
select_distinct_on .. failed
aggregates .. failed
transactions .. failed
random .. failed
portals .. failed
misc .. ./regress.sh: sql/misc.sql: cannot open
diff: cannot stat results/misc.out: No such file or directory (error 2)
ok
arrays .. failed
btree_index .. failed
hash_index .. failed
select_views .. failed
alter_table .. failed
purge .. failed
portals_p2 .. failed

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

From scrappy
Date: Wed, 05 Nov 1997 08:53:40 -0600
From: Scott Bell <scott@computer.org>
Subject: subscribe

subscribe

From scrappy
Date: Wed, 05 Nov 1997 09:32:24 -0600
From: Scott Bell <scott@computer.org>
Subject: Problem with bootstrap

Hello Postgres Group. I'm having a bit of trouble with this one.
Any help would be greatly appreciated. Thanks in advance!

- -Scott

- ---------------------------------------------------------
Your name : Scott Bell
Your email address : scott@computer.org
Category : compile
Severity : serious

Summary: Compiling fails at bootstrap.c

System Configuration
- - --------------------
Operating System : SunOS 5.5.1
PostgreSQL version : 6.2
Compiler used : gcc 2.7.2

Hardware:
- - ---------
A lovely SPARC-1 workstation.


Versions of other tools:
- - ------------------------
gmake 3.74, flex 2.5.2

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

Problem Description:
- - --------------------
I get the following snipit when compiling:

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

gmake -C bootstrap all PORTNAME=sparc_solaris
gmake[2]: Entering directory `/home/bell/pgsql/src/backend/bootstrap'
/opt/bin/bison -y -d bootparse.y
grep -v "^#" boot.sed > sedfile
sed -f sedfile < y.tab.c > bootparse.c
mv y.tab.h bootstrap_tokens.h
rm -f y.tab.c sedfile
gcc -I../../include -I../../backend/port/sparc_solaris -Wall
- -Wmissing-prototy
pes -Dsparc_solaris -I.. -I../port/sparc_solaris -I../../include
- -Wno-error
- -c bootparse.c -o bootparse.o
/opt/depot/bison/lib/bison.simple: In function `Int_yyparse':
/opt/depot/bison/lib/bison.simple:294: warning: implicit declaration of
function
`Int_yyerror'
/opt/depot/bison/lib/bison.simple:354: warning: implicit declaration of
function
`Int_yylex'
flex bootscanner.l
grep -v "^#" boot.sed > sedfile
sed -f sedfile < lex.yy.c > bootscanner.c
rm -f lex.yy.c sedfile
gcc -I../../include -I../../backend/port/sparc_solaris -Wall
- -Wmissing-prototy
pes -Dsparc_solaris -I.. -I../port/sparc_solaris -I../../include
- -Wno-error
- -c bootscanner.c -o bootscanner.o
lex.Int_yy.c:678: warning: no previous prototype for `Int_yylex'
bootscanner.l:138: warning: no previous prototype for `Int_yyerror'
gcc -I../../include -I../../backend/port/sparc_solaris -Wall
- -Wmissing-prototy
pes -Dsparc_solaris -I.. -I../port/sparc_solaris -I../../include
- -Wno-error
- -c bootstrap.c -o bootstrap.o
bootstrap.c:161: `F_BOOLIN' undeclared here (not in a function)
bootstrap.c:161: initializer element for `Procid[0].inproc' is not
constant
bootstrap.c:161: `F_BOOLOUT' undeclared here (not in a function)
bootstrap.c:161: initializer element for `Procid[0].outproc' is not
constant
bootstrap.c:162: `F_BYTEAIN' undeclared here (not in a function)
bootstrap.c:162: initializer element for `Procid[1].inproc' is not
constant
bootstrap.c:162: `F_BYTEAOUT' undeclared here (not in a function)
bootstrap.c:162: initializer element for `Procid[1].outproc' is not
constant
bootstrap.c:163: `F_CHARIN' undeclared here (not in a function)
bootstrap.c:163: initializer element for `Procid[2].inproc' is not
constant
bootstrap.c:163: `F_CHAROUT' undeclared here (not in a function)
bootstrap.c:163: initializer element for `Procid[2].outproc' is not
constant
bootstrap.c:164: `F_NAMEIN' undeclared here (not in a function)
bootstrap.c:164: initializer element for `Procid[3].inproc' is not
constant
bootstrap.c:164: `F_NAMEOUT' undeclared here (not in a function)
bootstrap.c:164: initializer element for `Procid[3].outproc' is not
constant
bootstrap.c:165: `F_CHAR16IN' undeclared here (not in a function)
bootstrap.c:165: initializer element for `Procid[4].inproc' is not
constant
bootstrap.c:165: `F_CHAR16OUT' undeclared here (not in a function)
bootstrap.c:165: initializer element for `Procid[4].outproc' is not
constant
bootstrap.c:167: `F_INT2IN' undeclared here (not in a function)
bootstrap.c:167: initializer element for `Procid[5].inproc' is not
constant
bootstrap.c:167: `F_INT2OUT' undeclared here (not in a function)
bootstrap.c:167: initializer element for `Procid[5].outproc' is not
constant
bootstrap.c:168: `F_INT28IN' undeclared here (not in a function)
bootstrap.c:168: initializer element for `Procid[6].inproc' is not
constant
bootstrap.c:168: `F_INT28OUT' undeclared here (not in a function)
bootstrap.c:168: initializer element for `Procid[6].outproc' is not
constant
bootstrap.c:169: `F_INT4IN' undeclared here (not in a function)
bootstrap.c:169: initializer element for `Procid[7].inproc' is not
constant
bootstrap.c:169: `F_INT4OUT' undeclared here (not in a function)
bootstrap.c:169: initializer element for `Procid[7].outproc' is not
constant
bootstrap.c:170: `F_REGPROCIN' undeclared here (not in a function)
bootstrap.c:170: initializer element for `Procid[8].inproc' is not
constant
bootstrap.c:170: `F_REGPROCOUT' undeclared here (not in a function)
bootstrap.c:170: initializer element for `Procid[8].outproc' is not
constant
bootstrap.c:171: `F_TEXTIN' undeclared here (not in a function)
bootstrap.c:171: initializer element for `Procid[9].inproc' is not
constant
bootstrap.c:171: `F_TEXTOUT' undeclared here (not in a function)
bootstrap.c:171: initializer element for `Procid[9].outproc' is not
constant
bootstrap.c:172: `F_INT4IN' undeclared here (not in a function)
bootstrap.c:172: initializer element for `Procid[10].inproc' is not
constant
bootstrap.c:172: `F_INT4OUT' undeclared here (not in a function)
bootstrap.c:172: initializer element for `Procid[10].outproc' is not
constant
bootstrap.c:173: `F_TIDIN' undeclared here (not in a function)
bootstrap.c:173: initializer element for `Procid[11].inproc' is not
constant
bootstrap.c:173: `F_TIDOUT' undeclared here (not in a function)
bootstrap.c:173: initializer element for `Procid[11].outproc' is not
constant
bootstrap.c:174: `F_XIDIN' undeclared here (not in a function)
bootstrap.c:174: initializer element for `Procid[12].inproc' is not
constant
bootstrap.c:174: `F_XIDOUT' undeclared here (not in a function)
bootstrap.c:174: initializer element for `Procid[12].outproc' is not
constant
bootstrap.c:175: `F_CIDIN' undeclared here (not in a function)
bootstrap.c:175: initializer element for `Procid[13].inproc' is not
constant
bootstrap.c:175: `F_CIDOUT' undeclared here (not in a function)
bootstrap.c:175: initializer element for `Procid[13].outproc' is not
constant
bootstrap.c:176: `F_OID8IN' undeclared here (not in a function)
bootstrap.c:176: initializer element for `Procid[14].inproc' is not
constant
bootstrap.c:176: `F_OID8OUT' undeclared here (not in a function)
bootstrap.c:176: initializer element for `Procid[14].outproc' is not
constant
bootstrap.c:177: `F_SMGRIN' undeclared here (not in a function)
bootstrap.c:177: initializer element for `Procid[15].inproc' is not
constant
bootstrap.c:177: `F_SMGROUT' undeclared here (not in a function)
bootstrap.c:177: initializer element for `Procid[15].outproc' is not
constant
bootstrap.c:178: `F_ARRAY_IN' undecllared here (not in a function)
bootstrap.c:178: initializer element for `Procid[16].inproc' is not
constant
bootstrap.c:178: `F_ARRAY_OUT' undeclared here (not in a function)
bootstrap.c:178: initializer element for `Procid[16].outproc' is not
constant
bootstrap.c:179: `F_ARRAY_IN' undeclared here (not in a function)
bootstrap.c:179: initializer element for `Procid[17].inproc' is not
constant
bootstrap.c:179: `F_ARRAY_OUT' undeclared here (not in a function)
bootstrap.c:179: initializer element for `Procid[17].outproc' is not
constant
gmake[2]: *** [bootstrap.o] Error 1
gmake[2]: Leaving directory `/home/bell/pgsql/src/backend/bootstrap'
gmake[1]: *** [bootstrap.dir] Error 2
gmake[1]: Leaving directory `/home/bell/pgsql/src/backend'
gmake: *** [all] Error 2

From scrappy
Date: Wed, 05 Nov 1997 17:24:13 +0000
From: Dr Stephen Henson <shenson@bigfoot.com>
Subject: Re: [PORTS] Problem with bootstrap

I had a similar problem under SCO. It was caused by an earlier problem
when fmgr.h was built and it couldn't find cpp. The actual constants
mentioned should be in fmgr.h when it is built. There is a script called
Gen_fmgr.sh or something like that which calls cpp. You can either
modify the scripts of change things so it can find cpp.

There was another script later on with a similar problem.

That fixed one problem for me (though there are others still to be
resolved).

Steve.

From scrappy
Date: Wed, 5 Nov 1997 11:53:49 -0800
From: hotz@jpl.nasa.gov (Henry B. Hotz)
Subject: Re: [PORTS] bug report on Solaris x86 2.5.1

At 9:25 AM 11/4/97, "Francisco Jos=E9 Esteban Risue=F1o" >6.- I'm rather
surprised about the fact that in every compilation the
src/backend/port/sparc_solaris was included, instead of
/src/backend/port/i386_solaris, which contains the same files, but with
different contents.
Sounds like there may be a problem with the template file, or how it's
being interpreted. You shouldn't have to do so many things just to get it
to build.
abstime .. failed
tinterval .. failed
horology .. failed
I think these should work if you have the time zone set correctly before
starting the postmaster.

The regression differences for int and oid types are probably just the
different error text for a divide by zero. You may want to look at the
diff on actual output files for the other "failures". FWIW I am running
6.1.1 on Solaris 2.5/sparc with no problems.

Wish I could help more. Good luck.

Signature failed Preliminary Design Review.
=46easibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu

From scrappy
Date: Wed, 5 Nov 1997 16:19:15 -0500 (EST)
From: Travis Melhiser <melhiser@viper.co.union.nc.us>
Subject: subscribe

subscribe

From scrappy
Date: Wed, 5 Nov 1997 16:19:45 -0500 (EST)
From: Travis Melhiser <melhiser@viper.co.union.nc.us>
Subject: Postgresql 6.2.1 and Linux/Alpha

I've been trying for several days with no success to compile
Postgresql on an Alpha running Linux.

The error on compile is as follows:

gcc -I../../../include -I/usr/include/ncurses -I/usr/include/readline -O2 -Wall -Wmissing-prototypes -Dlinux -I../.. -I../../port/linux -I../../../include -c buf_init.c -o buf_init.o
buf_init.c: In function `InitBufferPool':
buf_init.c:236: parse error before `__asm__'
buf_init.c:236: warning: left-hand operand of comma expression has no effect
buf_init.c:236: parse error before `)'
make[3]: *** [buf_init.o] Error 1


The only way I have found to get around this compile problem is to
undefine something in include/os.h:

#define HAS_TEST_AND_SET
changing this to
#undef HAS_TEST_AND_SET

Postgresql will compile at this point, but when trying to run initdb, I get
this error and a core dump:

initdb: creating template database in /usr/local/pgsql/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
WARN:BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1

any help would be GREATLY appreciated.

Thanks,
Travis

From scrappy
Date: Wed, 5 Nov 1997 16:31:18 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Apppears to have a problem with compiling a portion of code dealing with locking memory

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


Your name : Travis Melhiser
Your email address : melhiser@co.union.nc.us

Category : install: compile
Severity : critical

Summary: Apppears to have a problem with compiling a portion of code dealing with locking memory

System Configuration
- --------------------
Operating System : Linux 2.0.30 Alpha, RedHat 4.2

PostgreSQL version : 6.2.1

Compiler used : gcc 2.72

Hardware:
- ---------
Alpha 166Mhz, UDB
Linux FireWall.Mythos.Org 2.0.30 #31 Thu Aug 14 12:31:10 EDT 1997 alpha unknown


Versions of other tools:
- ------------------------
GNU Make version 3.75
flex version 2.5.4


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

Problem Description:
- --------------------
During Compile it fails to compile buf_init.c and any other
source piece that has the #define HAS_TEST_AND_SET
set. By undefining this, it will compile, but when
trying to run initdb, it fails.
Here are the respective errors:

gcc -I../../../include -I/usr/include/ncurses -I/usr/include/readline -O2 -Wall -Wmissing-prototypes -Dlinux -I../.. -I../../port/linux -I../../../include -c buf_init.c -o buf_init.o
buf_init.c: In function `InitBufferPool':
buf_init.c:236: parse error before `__asm__'
buf_init.c:236: warning: left-hand operand of comma expression has no effect
buf_init.c:236: parse error before `)'
make[3]: *** [buf_init.o] Error 1

initdb: creating template database in /usr/local/pgsql/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
WARN:BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1



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

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


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

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


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

From scrappy
Date: Wed, 5 Nov 1997 17:37:12 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Port Bug Report: Apppears to have a problem with compiling a portion of code dealing with locking memory

We have having trouble getting Alpha-Linux working with PostgreSQL
because of the processor specific stuff in storage/s_lock.h.

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


Your name : Travis Melhiser
Your email address : melhiser@co.union.nc.us

Category : install: compile
Severity : critical

Summary: Apppears to have a problem with compiling a portion of code dealing with locking memory

System Configuration
--------------------
Operating System : Linux 2.0.30 Alpha, RedHat 4.2

PostgreSQL version : 6.2.1

Compiler used : gcc 2.72

Hardware:
---------
Alpha 166Mhz, UDB
Linux FireWall.Mythos.Org 2.0.30 #31 Thu Aug 14 12:31:10 EDT 1997 alpha unknown


Versions of other tools:
------------------------
GNU Make version 3.75
flex version 2.5.4


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

Problem Description:
--------------------
During Compile it fails to compile buf_init.c and any other
source piece that has the #define HAS_TEST_AND_SET
set. By undefining this, it will compile, but when
trying to run initdb, it fails.
Here are the respective errors:

gcc -I../../../include -I/usr/include/ncurses -I/usr/include/readline -O2 -Wall -Wmissing-prototypes -Dlinux -I../.. -I../../port/linux -I../../../include -c buf_init.c -o buf_init.o
buf_init.c: In function `InitBufferPool':
buf_init.c:236: parse error before `__asm__'
buf_init.c:236: warning: left-hand operand of comma expression has no effect
buf_init.c:236: parse error before `)'
make[3]: *** [buf_init.o] Error 1

initdb: creating template database in /usr/local/pgsql/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
WARN:BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1



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

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


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

Solution:
---------


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


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

From scrappy
Date: Thu, 06 Nov 1997 14:07:34 +0200
From: Jouko Holopainen <jouko.holopainen@xnet.otm.fi>
Subject: Non-success

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


Your name : Jouko Holopainen
Your email address : jouko.holopainen@xnet.fi


System Configuration
- ---------------------
Architecture (example: Intel Pentium) : Intel 486/100

Operating System (example: Linux 2.0.26 ELF) : Solaris 2.5.1 / x86

uname -a : SunOS unix1 5.5.1 Generic_103641-08 i86pc i386 i86pc

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

Compiler used (example: gcc 2.7.2) : gcc 2.7.2


Please enter a FULL description of your problem:
- ------------------------------------------------
ALL regression tests fail with either:
Connection to database 'regression' failed.
FATAL 1:Database regression does not exist in pg_database
or:
Connection to database 'regression' failed.
PQexec() -- Request was sent to backend, but backend closed the channel before
responding. This probably means the backend terminated abnormally before or
while processing the request.

"createdb regression" gives no error. "postmaster -s" outputs:
regression1036regression
(1036 = UID of postgres). The data/base/regression directory is created.
If I then try to "destroydb regression" postmaster gives
WARN:destroydb: database regression does not exist.
If I try (again) "createdb regression" postmaster gives
mkdir: Failed to make directory "/usr/local/pgsql/data/base/regression"; File
exists
regression1036regression
The createdb gives no error.

If I try "psql regression" I get:
FATAL 1:Database regression does not exist in pg_database

If I try "psql template1" it works (i.e. I have done initdb).


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


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

- --
Jouko Holopainen / X-Net Oy | jouko.holopainen@xnet.fi
P.O. Box 100 | http://www.xnet.fi/
FIN-90501 Oulu | Tel: +358 8 551 3578
FINLAND | Fax: +358 8 551 3565

From scrappy
Date: Wed, 05 Nov 1997 13:49:12 +0100
From: "Francisco =?iso-8859-1?Q?Jos=E9?= Esteban =?iso-8859-1?Q?Risue=F1o?=" <Franciscojose.Esteban@dgp.mir.es>
Subject: Re: [PORTS] bug report on Solaris x86 2.5.1

Este es un mensaje multipartes en formato MIME.
- --------------561CBBD0075CCD9F516C7FB5
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable



Henry B. Hotz wrote:
At 9:25 AM 11/4/97, "Francisco Jos=E9 Esteban Risue=F1o" >6.- I'm rathe= r
surprised about the fact that in every compilation the
src/backend/port/sparc_solaris was included, instead of
/src/backend/port/i386_solaris, which contains the same files, but wit=
h
different contents.
Sounds like there may be a problem with the template file, or how it's
being interpreted. You shouldn't have to do so many things just to get= it
to build.
Has anyone a right template file for Solaris x86?
abstime .. failed
tinterval .. failed
horology .. failed
I think these should work if you have the time zone set correctly befor= e
starting the postmaster.
It's funny, if I put my time zone (GMT) instead of the Berkeley one, I pa=
ss
the timeinterval and horology tests
Wish I could help more. Good luck.
Any idea about the core dumped when I insert more than three columns by f=
ile
in a table?

- --
Saludos Cordiales,

______________________________________________________
Francisco Jos=E9 Esteban Risue=F1o
Jefe de Proyecto
=C1rea de Inform=E1tica - Direcci=F3n General de la Polic=EDa
tfno. (91) 890 22 11 fax. (91) 890 20 18
El Escorial (Madrid - Espa=F1a)
______________________________________________________


- --------------561CBBD0075CCD9F516C7FB5
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Tarjeta de Francisco José Esteban Risueño
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Francisco José Esteban Risueño
n: Esteban Risueño;Francisco José
org: Dirección General de la Policía. Área de Informática
adr: Ctra. M-505 km. 5.5;;;El Escorial;Madrid;28280;España
email;internet: Franciscojose.Esteban@dgp.mir.es
title: Jefe de Proyecto
tel;work: (91) 890 22 11
tel;fax: (91) 890 20 18
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard


- --------------561CBBD0075CCD9F516C7FB5--

From scrappy
Date: Wed, 5 Nov 1997 11:01:02 -0500 (EST)
From: Travis Melhiser <melhiser@viper.co.union.nc.us>
Subject: PostgreSQL 6.2.1 and Linux Alpha

Are there anyone with 6.2.1 running on Linux/Alpha?
It appeared to have successfully compiled and installed
the binaries, but when I try to exec initdb I receive this
error:

initdb: creating template database in /usr/local/pgsql/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
WARN:BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1

Any Help on compiling this on the Linux/Alpha platform?

Thanks,
Travis

From scrappy
Date: Fri, 7 Nov 1997 10:08:53 +0000 ()
From: "Kenji T. Hollis" <khollis@Gawain.Houston-InterWeb.COM>
Subject: PostGreSQL Alpha Question

Hello all.

I'm not sure where to post this type of question, as I'm not sure if it's
a bug or user error on my part. However, I will ask in these three
mailing lists.

I have an Alpha PC164 533MHz machine, and I am trying to get PostGreSQL
6.2.1 to compile here. In order to do so, I have to comment out the
following entries in alpha.h and linux.h in src/include/port:

#define HAS_TEST_AND_SET
to:
#undef HAS_TEST_AND_SET

The reason is, if I don't do this, backend/storage/buffer dies in
init_buf.c at a line reading:

#ifdef HAS_TEST_AND_SET
S_INIT_LOCK(&(buf->io_in_progress_lock));
#endif

This complains about an unknown command __asm__.

If I take out HAS_TEST_AND_SET, it compiles just fine, and everything
seems to install perfectly.

However, when I try running initdb from the bin directory (with everything
installed correctly), I get the following output:

initdb: using /var/lib/postgresql/local1_template1.bki.source as input to
create the template database.
initdb: using /var/lib/postgresql/global1.bki.source as input to create
the global classes.
initdb: using /var/lib/postgresql/pg_hba.conf.sample as the host-based
authentication control file.

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

initdb: creating template database in
/var/lib/postgresql/data/base/template1
Running: postgres -boot -C -F -D/var/lib/postgresql/data -Q template1
WARN:BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist

nimue kernel: postgres: memory violation at pc=00000000 rp=00000000 (bad
address = 00000000)

initdb: could not create template database
initdb: cleaning up by wiping out /var/lib/postgresql/data/base/template1

Note the memory violation.

I have tried this with version 6.2, 6.1, and 6.0, and I get EXACTLY the
same problem. It's almost as if PostGreSQL is not 64-bit aware yet.

Can anyone please give me a solution? I *need* to have this solution
working - we are using it for a very large scale project, and I was
supposed to have this up-and-running yesterday.

I would appreciate any help, comments, or suggestions you may be able to
give. At this point, I have spent 6 days on it, and I have lost all
chance of becoming hopeful...

- -- Ken
- ------
===========================================================================
Houston Interweb Design, Inc. || Borland C++Builder, Gnu C++,
Programmer and Sys/Net Admin || Perl 5, Pascal, and Linux to go
C/C++/Perl/HTML/CGI/GUI || (With a side of fries, please)
===========================================================================

From scrappy
Date: 07 Nov 1997 18:57:04 +0100
From: ebert@pem10.pe-muc.de (R. Ebert)
Subject: Re: [QUESTIONS] PostGreSQL Alpha Question
"KTH" == Kenji T Hollis <khollis@Gawain.Houston-InterWeb.COM> writes:
[problem description deleted]

KTH> I have tried this with version 6.2, 6.1, and 6.0, and I get EXACTLY
KTH> the same problem. It's almost as if PostGreSQL is not 64-bit aware
KTH> yet.

I second your opinion, Postgresql does not run properly on 64-bit alpha
architecture.

I recently posted a question on pgsql-questions about timezone handling,
which turned out to be a bug.

Running the backend on a terminal compiled with -DDATEDEBUG, made me
think that the global variable "timezone" in not properly initialized.
I spent a whole day trying to fix it to no avail.

If someone else want to look into it, I can provide example runs.

Rolf
ebert@pe-muc.de

From scrappy
Date: Fri, 7 Nov 1997 12:55:31 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [BUGS] PostGreSQL Alpha Question
Can anyone please give me a solution? I *need* to have this solution
working - we are using it for a very large scale project, and I was
supposed to have this up-and-running yesterday.

I would appreciate any help, comments, or suggestions you may be able to
give. At this point, I have spent 6 days on it, and I have lost all
chance of becoming hopeful...
We have problems on alpha linux, and people are working on it. Here is
a patch I got from someone several days ago that has a new s_lock.h for
alpha linux. He also reports problems after this. Please feel free to
contact him and work together to get this port working.

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

From melhiser@viper.co.union.nc.us Thu Nov 6 19:13:32 1997
Received: from viper.co.union.nc.us (co.union.nc.us [199.90.44.2])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id TAA08995
for <maillist@candle.pha.pa.us>; Thu, 6 Nov 1997 19:13:28 -0500 (EST)
Received: (from melhiser@localhost)
by viper.co.union.nc.us (8.8.5/8.8.5) id UAA28831
for maillist@candle.pha.pa.us; Thu, 6 Nov 1997 20:08:40 -0500
From: Travis Melhiser <melhiser@viper.co.union.nc.us>
Message-Id: <199711070108.UAA28831@viper.co.union.nc.us>
From scrappy
Date: Thu, 6 Nov 1997 20:08:40 -0500 (EST)
In-Reply-To: <199711052237.RAA14881@candle.pha.pa.us> from "Bruce Momjian" at Nov 5, 97 05:37:12 pm
Content-Type: text
Status: OR
We have having trouble getting Alpha-Linux working with PostgreSQL
because of the processor specific stuff in storage/s_lock.h.
I have fixed the ASM pieces in stoarage/s_lock.h
for the alpha.

I'll submit those here as well, but now that the compile
happens cleanly, I get an error while trying to run initdb.

Here it is as follows:

initdb: using /usr/local/pgsql/lib/local1_template1.bki.source as input to create the template database.
initdb: using /usr/local/pgsql/lib/global1.bki.source as input to create the global classes.
initdb: using /usr/local/pgsql/lib/pg_hba.conf.sample as the host-based authentication control file.

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

initdb: creating template database in /usr/local/pgsql/data/base/template1
Running: postgres -boot -C -F -D/usr/local/pgsql/data -Q template1
WARN:BuildFuncTupleDesc: function mkoidname(opaque, opaque) does not exist
initdb: could not create template database
initdb: cleaning up by wiping out /usr/local/pgsql/data/base/template1


- ------------
This doesn't appear to be related to the s_lock.h problem, is it?
when I do:
nm postgres |grep mkoidname
I get:
0000000120109f60 T mkoidname
0000000120109f68 t mkoidname..ng

Do you have any hints on where I might start looking?

Here is the s_lock.h file, I was not sure how you wanted the diff, so I
just sent the entire piece.

Thanks,
Travis

#################################################################

/*-------------------------------------------------------------------------
*
* s_lock.h--
* This file contains the implementation (if any) for spinlocks.
*
* Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* $Header: /usr/local/cvsroot/pgsql/src/include/storage/s_lock.h,v 1.10 1997/10/03 15:27:18 momjian Exp $
*
*-------------------------------------------------------------------------
*/
/*
* DESCRIPTION
* The following code fragment should be written (in assembly
* language) on machines that have a native test-and-set instruction:
*
* void
* S_LOCK(char_address)
* char *char_address;
* {
* while (test_and_set(char_address))
* ;
* }
*
* If this is not done, POSTGRES will default to using System V
* semaphores (and take a large performance hit -- around 40% of
* its time on a DS5000/240 is spent in semop(3)...).
*
* NOTES
* AIX has a test-and-set but the recommended interface is the cs(3)
* system call. This provides an 8-instruction (plus system call
* overhead) uninterruptible compare-and-set operation. True
* spinlocks might be faster but using cs(3) still speeds up the
* regression test suite by about 25%. I don't have an assembler
* manual for POWER in any case.
*
*/
#ifndef S_LOCK_H
#define S_LOCK_H

#include "storage/ipc.h"

#if defined(HAS_TEST_AND_SET)

#if defined (nextstep)
/*
* NEXTSTEP (mach)
* slock_t is defined as a struct mutex.
*/
#define S_LOCK(lock) mutex_lock(lock)

#define S_UNLOCK(lock) mutex_unlock(lock)

#define S_INIT_LOCK(lock) mutex_init(lock)

/* S_LOCK_FREE should return 1 if lock is free; 0 if lock is locked */
/* For Mach, we have to delve inside the entrails of `struct mutex'. Ick! */
#define S_LOCK_FREE(alock) ((alock)->lock == 0)

#endif /* next */



#if defined(irix5)
/*
* SGI IRIX 5
* slock_t is defined as a struct abilock_t, which has a single unsigned long
* member.
*
* This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
* assembly from his NECEWS SVR4 port, but we probably ought to retain this
* for the R3000 chips out there.
*/
#define S_LOCK(lock) do \
{ \
while (!acquire_lock(lock)) \
; \
} while (0)

#define S_UNLOCK(lock) release_lock(lock)

#define S_INIT_LOCK(lock) init_lock(lock)

/* S_LOCK_FREE should return 1 if lock is free; 0 if lock is locked */

#define S_LOCK_FREE(lock) (stat_lock(lock) == UNLOCKED)

#endif /* irix5 */


/*
* OSF/1 (Alpha AXP)
*
* Note that slock_t on the Alpha AXP is msemaphore instead of char
* (see storage/ipc.h).
*/

#if (defined(__alpha__) || defined(__alpha)) && !defined(linux)

#define S_LOCK(lock) do \
{ \
while (msem_lock((lock), MSEM_IF_NOWAIT) < 0) \
; \
} while (0)

#define S_UNLOCK(lock) msem_unlock((lock), 0)

#define S_INIT_LOCK(lock) msem_init((lock), MSEM_UNLOCKED)

#define S_LOCK_FREE(lock) (!(lock)->msem_state)

#endif /* alpha */

/*
* Solaris 2
*/

#if defined(i386_solaris) || \
defined(sparc_solaris)
/* for xxxxx_solaris, this is defined in port/.../tas.s */

static int tas(slock_t *lock);

#define S_LOCK(lock) do \
{ \
while (tas(lock)) \
; \
} while (0)

#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

#endif /* i86pc_solaris || sparc_solaris */

/*
* AIX (POWER)
*
* Note that slock_t on POWER/POWER2/PowerPC is int instead of char
* (see storage/ipc.h).
*/

#if defined(aix)

#define S_LOCK(lock) do \
{ \
while (cs((int *) (lock), 0, 1)) \
; \
} while (0)

#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

#endif /* aix */

/*
* HP-UX (PA-RISC)
*
* Note that slock_t on PA-RISC is a structure instead of char
* (see storage/ipc.h).
*/

#if defined(hpux)

/*
* a "set" slock_t has a single word cleared. a "clear" slock_t has
* all words set to non-zero.
*/
static slock_t clear_lock = {-1, -1, -1, -1};

static int tas(slock_t *lock);

#define S_LOCK(lock) do \
{ \
while (tas(lock)) \
; \
} while (0)

#define S_UNLOCK(lock) (*(lock) = clear_lock) /* struct assignment */

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

#define S_LOCK_FREE(lock) ( *(int *) (((long) (lock) + 15) & ~15) != 0)

#endif /* hpux */

/*
* sun3
*/

#if defined(sun3)

static int tas(slock_t *lock);

#define S_LOCK(lock) do \
{ \
while (tas(lock)) \
; \
} while (0)

#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

static int
tas_dummy()
{
asm("LLA0:");
asm(" .data");
asm(" .text");
asm("|#PROC# 04");
asm(" .globl _tas");
asm("_tas:");
asm("|#PROLOGUE# 1");
asm(" movel sp@(0x4),a0");
asm(" tas a0@");
asm(" beq LLA1");
asm(" moveq #-128,d0");
asm(" rts");
asm("LLA1:");
asm(" moveq #0,d0");
asm(" rts");
asm(" .data");
}

#endif /* sun3 */

/*
* sparc machines
*/

#if defined(NEED_SPARC_TAS_ASM)

/* if we're using -ansi w/ gcc, use __asm__ instead of asm */
#if defined(__STRICT_ANSI__)
#define asm(x) __asm__(x)
#endif

static int tas(slock_t *lock);

static int
tas_dummy()
{
asm(".seg \"data\"");
asm(".seg \"text\"");
asm(".global _tas");
asm("_tas:");

/*
* Sparc atomic test and set (sparc calls it "atomic load-store")
*/

asm("ldstub [%r8], %r8");

/*
* Did test and set actually do the set?
*/

asm("tst %r8");

asm("be,a ReturnZero");

/*
* otherwise, just return.
*/

asm("clr %r8");
asm("mov 0x1, %r8");
asm("ReturnZero:");
asm("retl");
asm("nop");
}

#define S_LOCK(addr) do \
{ \
while (tas(addr)) \
; \
} while (0)

/*
* addr should be as in the above S_LOCK routine
*/
#define S_UNLOCK(addr) (*(addr) = 0)

#define S_INIT_LOCK(addr) (*(addr) = 0)

#endif /* NEED_SPARC_TAS_ASM */

/*
* i386 based things
*/

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

#endif /* NEED_I386_TAS_ASM */


/* ############ Changes by Travis Melhiser 11-06-97 ############ */

#if defined(__alpha__) && defined(linux)

#define S_LOCK(lock) do { \
slock_t _res; \
do { \
__asm__(" ldq $0, %0 \n\
bne $0, already_set%= \n\
ldq_l $0, %0 \n\
bne $0, already_set%= \n\
or $31, 1, $0 \n\
stq_c $0, %0 \n\
beq $0, stqc_fail%= \n\
success%=: \n\
bis $31, $31, %1 \n\
mb \n\
jmp $31, end%= \n\
stqc_fail%=: or $31, 1, $0 \n\
already_set%=: bis $0, $0, %1 \n\
end%=: nop ": "=m"(*lock), "=r"(_res): :"0"); \
} while (_res != 0); \
} while (0)


#define S_UNLOCK(lock) ({ __asm__("mb \n"); *(lock) = 0; })

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

#endif /* defined(__alpha__) && defined(linux) */

/* ############ End Changes by Travis Melhiser 11-06-97 ############ */

#if (defined(linux) || defined(__NetBSD__)) && defined(sparc)

#define S_LOCK(lock) do \
{ \
slock_t _res; \
do \
{ \
__asm__("ldstub [%1], %0" \
: "=&r"(_res) \
: "r"(lock)); \
} while (_res != 0); \
} while (0)

#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

#endif /* defined(linux) && defined(sparc) */

#if defined(linux) && defined(PPC)

static int
tas_dummy()
{
__asm__(" \n\
tas: \n\
lwarx 5,0,3 \n\
cmpwi 5,0 \n\
bne fail \n\
addi 5,5,1 \n\
stwcx. 5,0,3 \n\
beq success \n\
fail: li 3,1 \n\
blr \n\
success: \n\
li 3,0 \n\
blr \n\
");
}

#define S_LOCK(lock) do \
{ \
while (tas(lock)) \
; \
} while (0)

#define S_UNLOCK(lock) (*(lock) = 0)

#define S_INIT_LOCK(lock) S_UNLOCK(lock)

#endif /* defined(linux) && defined(PPC) */

#ifndef S_LOCK_FREE /* for those who have not already defined it */
#define S_LOCK_FREE(lock) ((*lock) == 0)
#endif

#endif /* HAS_TEST_AND_SET */

#endif /* S_LOCK_H */



#################################################################


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

From scrappy
Date: Fri, 7 Nov 1997 12:05:08 +0000 ()
From: "Kenji T. Hollis" <khollis@Gawain.Houston-InterWeb.COM>
Subject: Re: [QUESTIONS] PostGreSQL Alpha Question

I don't know anything about the timestamps, as I haven't really relied on
them that much. I recently received a new s_lock.h file, and I will look
in to the other problems I'm having. If I find anything out, I'll send
everyone a patch that *may* work. (Note the "may")

- -- Ken
- ------
===========================================================================
Houston Interweb Design, Inc. || Borland C++Builder, Gnu C++,
Programmer and Sys/Net Admin || Perl 5, Pascal, and Linux to go
C/C++/Perl/HTML/CGI/GUI || (With a side of fries, please)
===========================================================================
On 7 Nov 1997, R. Ebert wrote:

"KTH" == Kenji T Hollis <khollis@Gawain.Houston-InterWeb.COM> writes:
[problem description deleted]

KTH> I have tried this with version 6.2, 6.1, and 6.0, and I get EXACTLY
KTH> the same problem. It's almost as if PostGreSQL is not 64-bit aware
KTH> yet.

I second your opinion, Postgresql does not run properly on 64-bit alpha
architecture.

I recently posted a question on pgsql-questions about timezone handling,
which turned out to be a bug.

Running the backend on a terminal compiled with -DDATEDEBUG, made me
think that the global variable "timezone" in not properly initialized.
I spent a whole day trying to fix it to no avail.

If someone else want to look into it, I can provide example runs.

Rolf
ebert@pe-muc.de
From scrappy
Date: Sat, 8 Nov 1997 06:59:56 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: dlfcn.h is missing!

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


Your name : Ionut Muntean
Your email address : delta@deltanet.roknet.ro

Category : install: compile
Severity : serious

Summary: dlfcn.h is missing!

System Configuration
- --------------------
Operating System : Linux ELF 2.0.0

PostgreSQL version : Latest

Compiler used : Latest

Hardware:
- ---------
Pentium 32 Mb Ram

Versions of other tools:
- ------------------------
make, flex 2.5.4

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

Problem Description:
- --------------------
cannot compile postgresql because of the missing file

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

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


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

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


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

From scrappy
Date: Fri, 07 Nov 1997 10:21:19 -0700
From: Tony Rossignol <tonyr@ep.newtimes.com>
Subject: Alpha Linux Port???

Is there an Alpha Linux port of PostgreSQL??

If so where can I find it?
- --
- -------------------------------
tonyr@ep.newtimes.com
Directory of Web Technology
Newtimes Inc.
- -------------------------------

From scrappy
Date: Sun, 09 Nov 1997 01:33:43 +0000
From: Dr Stephen Henson <shenson@bigfoot.com>
Subject: Problems with SCO.

Further to my initial report I've made some progress compiling
PostgreSQL under SCO 3.2v5.0.2. Most progress was made by: setting
USE_POSIX_SIGNALS, applying the 8 byte memory alignment patch and
setting gcc to export symbols from postgres binary.

However quite a few problems remain.

The regress program "triggers" fails and outputs the error:

WARN:CreateTrigger: function check_primary_key () does not exist

It used to complain about not being able to load refint.so and
regress.so due to relocation errors (which was cured by exporting stuff
from postgres).

Another problem relates to the "oid" test:

QUERY: INSERT INTO OID_TBL(f1) VALUES ('');
WARN:pg_atoi: error reading "": Invalid argument

The expected result is for strtol (which pg_atoi calls) to correctly
consider the empty string to be valid and zero. The SCO version does
not.

Steve.

From scrappy
Date: Sun, 09 Nov 1997 22:10:01 +0100
From: Tamas Laufer <lt660@ipisun.jpte.hu>
Subject: Re: [PORTS] Problems with SCO.

Dr Stephen Henson wrote:
Further to my initial report I've made some progress compiling
PostgreSQL under SCO 3.2v5.0.2. Most progress was made by: setting
USE_POSIX_SIGNALS, applying the 8 byte memory alignment patch and
setting gcc to export symbols from postgres binary.
Many thank for your suggestion to USE_POSIX_SIGNALS in config.h.
I threw away my signal-handler reinits. Your solution is more
comfortable. It works fine with the *native cc* of SCO 3.2v5.0.2 too.
I realized: POSIX SIGNALS == "sigaction". (Is this true ?)
And (by SCO manuals) the sigaction is preferred over signal.
However quite a few problems remain.

The regress program "triggers" fails and outputs the error:

WARN:CreateTrigger: function check_primary_key () does not exist

It used to complain about not being able to load refint.so and
regress.so due to relocation errors (which was cured by exporting
stuff from postgres).
I can't imagine why it is. My version (compiled with the SCO's cc) don't
produce this phenomenon. I have gcc 2.7.2.1 created from sources with
very large effort. It has problems at creation of elf objects. It
successfully compiled the tcl7.5, Tk4.1 and huge Objc libraries. But
rarely it produces code-generation mistakes.
Another problem relates to the "oid" test:

QUERY: INSERT INTO OID_TBL(f1) VALUES ('');
WARN:pg_atoi: error reading "": Invalid argument

The expected result is for strtol (which pg_atoi calls) to correctly
consider the empty string to be valid and zero. The SCO version does
not.
Thank, according to your diagnosis I cured the pg_atoi with separating
the case of empty-string param. *It* works fine. But possibly not
everything ...

Note: some arithmetical error messages differ from those given in the
./regress/results/expec*/*.out. E.g. I got "invalid argument" where the
"parse error" expected. So the int2, int4, float8 and oid tests get
failed.

Note2: for GNU configure script writers about the "-ldl" on SCO
3.2v5.0.2. The content of libdl.so follows (by nm /usr/lib/libdl.so):
_______________
Symbols from /usr/lib/libdl.so:

[Index] Value Size Type Bind Other Shndx Name

[1] | 0| 0|SECT |LOCL |0 |1 |.note
_______________

The dlopen, dlsym and dlclose are macros in <dlfcn.h>. The
/usr/lib/libc.so contains the _dlopen, _dlsym and _dlclose referred by
the dlfcn.h.


Best regards,
Tamas

PS. These are my (slightly commented) test results:

=============== destroying old regression database... =================
=============== creating new regression database... =================
=============== running regression queries... =================
boolean .. ok
char .. ok
char16 .. ok
char2 .. ok
char4 .. ok
char8 .. ok
text .. ok
int2 .. failed
int4 .. failed
oid .. failed
oidint2 .. failed
oidint4 .. failed
oidname .. ok
float4 .. ok
float8 .. failed
numerology .. ok
point .. ok
lseg .. ok
box .. ok
path .. ok
polygon .. ok
circle .. ok
geometry .. failed
timespan .. ok
datetime .. failed /* TZ=CET-1CETDST,M3.5.0/1,M10.5.0/1 */
reltime .. ok
abstime .. failed
tinterval .. failed
horology .. failed
comments .. ok
create_function_1 .. ok
create_type .. ok
create_table .. ok
create_function_2 .. ok
constraints .. ok
triggers .. ok
copy .. ok
create_misc .. ok
create_aggregate .. ok
create_operator .. ok
create_view .. ok
create_index .. ok
sanity_check .. failed /*!!! VACUUM: no. of index tuples differ... */
errors .. ok
select .. ok
select_into .. ok
select_distinct .. ok
select_distinct_on .. ok
aggregates .. ok
transactions .. ok
random .. failed
portals .. ok
misc .. failed
arrays .. ok
btree_index .. ok
hash_index .. ok
select_views .. failed
alter_table .. ok
purge .. ok
portals_p2 .. ok

_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

From scrappy
Date: Sun, 9 Nov 1997 21:13:13 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Problems with SCO.
Further to my initial report I've made some progress compiling
PostgreSQL under SCO 3.2v5.0.2. Most progress was made by: setting
USE_POSIX_SIGNALS, applying the 8 byte memory alignment patch and
setting gcc to export symbols from postgres binary.
I haven't forgotten about the alignment issue. I posted a question
about it, but no one replied.

However quite a few problems remain.

The regress program "triggers" fails and outputs the error:

WARN:CreateTrigger: function check_primary_key () does not exist

It used to complain about not being able to load refint.so and
regress.so due to relocation errors (which was cured by exporting stuff
from postgres).

Another problem relates to the "oid" test:

QUERY: INSERT INTO OID_TBL(f1) VALUES ('');
WARN:pg_atoi: error reading "": Invalid argument

The expected result is for strtol (which pg_atoi calls) to correctly
consider the empty string to be valid and zero. The SCO version does
not.

Steve.


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

From scrappy
Date: Sun, 9 Nov 1997 21:15:15 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [COMMITTERS] 'pgsql/src/template .similar'
Update of /usr/local/cvsroot/pgsql/src/template
In directory hub.org:/tmp/cvs-serv14410

Modified Files:
.similar
Log Message:

Add i586-pc-sco3.2v5.0.2 to .similar file

Pointed out by: Pieter Huyser <pieter@inetsys.alt.za>



Add i586-pc-sco3.2v5.0.2 to .similar file
I am going to remove the 5.0.2 because configure will strip them off
anyway, and we will match more SCO systems.


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

From scrappy
Date: Sun, 9 Nov 1997 21:17:37 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [COMMITTERS] 'pgsql/src/template .similar'
Update of /usr/local/cvsroot/pgsql/src/template
In directory hub.org:/tmp/cvs-serv15640

Modified Files:
.similar
Log Message:

Oops, shouldn't have added that extra, it seems... :)
Oops, looks like you caught the 5.0.2 issue.

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

From scrappy
Date: Mon, 10 Nov 1997 07:34:23 +0000
From: "Boersenspielteam" <boersenspiel@vocalweb.de>
Subject: mSQL ported to Win 32

Hi Hackers and Porters :-),

just read this in a newsgroup:

- --- snip

David Hughes' mini SQL (mSQL) Relational Database has been ported to
the Windows NT/95 using the free Cygnus GNU toolkit. The Cygnus
toolkit comprised the GNU 'C' compiler and various Unix utilities.

Details of the port along with a small patch file to get mSQL building
using the GNU toolkit are available at the following URL:-

<URL http://www.threewiz.demon.co.uk/software/>

This port has been tested with George Reese's Imaginary JDBC driver as
stand-alone applications and from within Java Web servlets.

- --
David Harvey-George
Email: David.George (at) threewiz.demon.co.uk
Web: www.threewiz.demon.co.uk

- --- snip

So it doesn't seem to be that difficult. How can we go forward to
encourage a port to Win? There seem to be people from time to time
willing to spend a little time on this. Normally they just get to
here: Uhh it's gonna tike a lot, I mean lot of time and they crawl
back ...

I'm an absolut non-programmer, so I can't help that much. Perhaps we
should set up a homepage with infos for people willing to port to
Win32. I'm sure, there are some Vadims, Bruces, et al out there and
they should work on the only real free database we all know as
PostgreSQL.

Thanx for the great job you're doing.

Bye

Tomas

Ciao

Das Boersenspielteam.

- ---------------------------------------------------------------------------
http://www.boersenspiel.de
Das Boersenspiel im Internet
*Realitaetsnah* *Kostenlos* *Ueber 6000 Spieler*
- ---------------------------------------------------------------------------

From scrappy
Date: Mon, 10 Nov 1997 10:16:09 +0000 (GMT)
From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Subject: Re: [QUESTIONS] PostGreSQL Alpha Question

R. Ebert writes:
"KTH" == Kenji T Hollis <khollis@Gawain.Houston-InterWeb.COM> writes:
[problem description deleted]

KTH> I have tried this with version 6.2, 6.1, and 6.0, and I get EXACTLY
KTH> the same problem. It's almost as if PostGreSQL is not 64-bit aware
KTH> yet.

I second your opinion, Postgresql does not run properly on 64-bit alpha
architecture.

I recently posted a question on pgsql-questions about timezone handling,
which turned out to be a bug.

Running the backend on a terminal compiled with -DDATEDEBUG, made me
think that the global variable "timezone" in not properly initialized.
I spent a whole day trying to fix it to no avail.

If someone else want to look into it, I can provide example runs.
Here's the bug report and fix that I sent in a couple of months ago.
I was asked to reproduce the problem/fix with 6.2beta but 6.2beta was
broken under Alpha for other reasons back then and it looks like the
fix was never incorporated.

- ------------------------------ cut here ------------------------------
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


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

Operating System (example: Linux 2.0.26 ELF) : Digital UNIX 4.0

PostgreSQL version (example: PostgreSQL-6.1) : PostgreSQL-6.1.1

Compiler used (example: gcc 2.7.2) : Native cc


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

Most datetime calculations are very broken (e.g. datetime.sql from
the distributed regression tests).


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

psql
select 'now'::datetime;

prints a random date in 2018 (for example).


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

The problem is the following lines around l2617 of DecodeDateTime
in backend/utils/adt/dt.c:

#ifdef HAVE_INT_TIMEZONE
*tzp = ((tm->tm_isdst > 0)? (timezone - 3600): timezone);

#else /* !HAVE_INT_TIMEZONE */
*tzp = -(tm->tm_gmtoff); /* tm_gmtoff is Sun/DEC-ism */
#endif

The initial configuration stage defines HAVE_INT_TIMEZONE in config.h.
However, under Digital UNIX, the symbol timezone is some pointer
picked up from somewhere. Interpreting that pointer as an offset adds
some ridiculous large number to the resulting times resulting in the
bogus datetime values. Rather than hack GNU configure tests properly,
I just changed the
#define HAVE_INT_TIMEZONE 1
line in include/config.h to
/* #undef HAVE_INT_TIMEZONE */
and verified that that fixed the problem. The datetime.sql regression
test still coughs up a few differences but it's mostly a second or two
of different rather than 21 years. I'll assume that's not important
unless I hear to the contrary.

- --Malcolm

- --
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

- ------------------------------ cut here ------------------------------

- --Malcolm


- --
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

From scrappy
Date: Mon, 10 Nov 1997 13:19:22 +0000
From: Dr Stephen Henson <shenson@bigfoot.com>
Subject: Re: [PORTS] Problems with SCO.

I've got a bit further. The problem with trigger appears to be caused by
the create_function_1 test. The first few lines of output read:

QUERY: CREATE FUNCTION widget_in(opaque)
RETURNS widget
AS
'/u/postgres/postgresql-6.2.1/src/test/regress/input/../regress.so'
LANGUAGE 'c';
NOTICE:ProcedureCreate: type 'widget' is not yet defined
FATAL 1:btree: items are out of order (leftmost 0, stack 1, update 1)
QUERY: CREATE FUNCTION widget_out(opaque)
RETURNS opaque
AS
'/u/postgres/postgresql-6.2.1/src/test/regress/input/../regress.so'
LANGUAGE 'c';
PQexec() -- Request was sent to backend, but backend closed the channel
before responding. This probably means the backend terminated
abnormally before or while processing the request.

If however I rerun create_function_1 without recreating the database all
is as expected and subsequent tests like triggers run fine. If I delete
and recreate the "regression" database and run create_function_1 only I
get the FATAL error above.

Has anyone any ideas what is causing this? I'll carry on looking but the
code involved looks a bit complicated (to say the least).

I suspect that when this is cleared up I will have a usable version.

Steve.

From scrappy
Date: Mon, 10 Nov 1997 23:26:12 -0700 (MST)
From: teunis <teunis@mauve.computersupportcentre.com>
Subject: Re: [HACKERS] mSQL ported to Win 32
On Mon, 10 Nov 1997, Boersenspielteam wrote:

Hi Hackers and Porters :-),

just read this in a newsgroup:

--- snip

David Hughes' mini SQL (mSQL) Relational Database has been ported to
the Windows NT/95 using the free Cygnus GNU toolkit. The Cygnus
toolkit comprised the GNU 'C' compiler and various Unix utilities.

Details of the port along with a small patch file to get mSQL building
using the GNU toolkit are available at the following URL:-

<URL http://www.threewiz.demon.co.uk/software/>
Thanks!
(now looking at porting postgres to win32... I'd rather use linux but my
boss discovered cygnus win-32 stuff and is making quiet threats :)
[sigh - well, at least it'll be a challenge... and a change from fighting
with Java-AWT code :]

G'day, eh? :)
- Teunis

From scrappy
Date: Tue, 11 Nov 1997 06:56:11 +0000 (GMT)
From: Peter T Mount <psqlhack@maidast.demon.co.uk>
Subject: Re: [HACKERS] mSQL ported to Win 32
On Mon, 10 Nov 1997, teunis wrote:
On Mon, 10 Nov 1997, Boersenspielteam wrote:

Hi Hackers and Porters :-),

just read this in a newsgroup:

--- snip

David Hughes' mini SQL (mSQL) Relational Database has been ported to
the Windows NT/95 using the free Cygnus GNU toolkit. The Cygnus
toolkit comprised the GNU 'C' compiler and various Unix utilities.

Details of the port along with a small patch file to get mSQL building
using the GNU toolkit are available at the following URL:-

<URL http://www.threewiz.demon.co.uk/software/>
Thanks!
(now looking at porting postgres to win32... I'd rather use linux but my
boss discovered cygnus win-32 stuff and is making quiet threats :)
[sigh - well, at least it'll be a challenge... and a change from fighting
with Java-AWT code :]
The only time I have trouble with the AWT is on win-32 ;-)
G'day, eh? :)
- Teunis

- --
Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk
Main Homepage: http://www.demon.co.uk/finder
Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk

From scrappy
Date: 11 Nov 1997 11:47:50 +0100
From: ebert@pem10.pe-muc.de (R. Ebert)
Subject: Re: [QUESTIONS] PostGreSQL Alpha Question
"MB" == Malcolm Beattie <mbeattie@sable.ox.ac.uk> writes:
MB> R. Ebert writes:
"KTH" == Kenji T Hollis <khollis@Gawain.Houston-InterWeb.COM>
writes:

[problem description deleted]
KTH> I have tried this with version 6.2, 6.1, and 6.0, and I get EXACTLY
KTH> the same problem. It's almost as if PostGreSQL is not 64-bit aware
KTH> yet.
I second your opinion, Postgresql does not run properly on 64-bit
alpha architecture.

I recently posted a question on pgsql-questions about timezone
handling, which turned out to be a bug.

Running the backend on a terminal compiled with -DDATEDEBUG, made me
think that the global variable "timezone" in not properly
initialized. I spent a whole day trying to fix it to no avail.

If someone else want to look into it, I can provide example runs.
MB> Here's the bug report and fix that I sent in a couple of months ago.

[bug report removed]

MB> The initial configuration stage defines HAVE_INT_TIMEZONE in
MB> config.h. However, under Digital UNIX, the symbol timezone is some
MB> pointer picked up from somewhere. Interpreting that pointer as an
MB> offset adds some ridiculous large number to the resulting times
MB> resulting in the bogus datetime values. Rather than hack GNU
MB> configure tests properly, I just changed the #define
MB> HAVE_INT_TIMEZONE 1 line in include/config.h to /* #undef
MB> HAVE_INT_TIMEZONE */ and verified that that fixed the problem. The
MB> datetime.sql regression test still coughs up a few differences but
MB> it's mostly a second or two of different rather than 21 years. I'll
MB> assume that's not important unless I hear to the contrary.

Editing config.h and undefining HAVE_INT_TIMEZONE solved the problem for
me, too. (OSF/1 3.0 or 3.2, gcc-2.7.2, postgres-6.2.1). The only
differences on the regression tests datetime, abstime, and tinterval
concern mixing up PST and PDT. That is a lot better than the unpatched
postgres 6.2.1.

Rolf
ebert@pe-muc.de

From scrappy
Date: Tue, 11 Nov 1997 05:52:16 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: upgrade from 1.09 to 6.2.1 does make serious problems

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


Your name : Steffen Krug
Your email address : steffen.krug@usa.net

Category : runtime: back-end
Severity : serious

Summary: upgrade from 1.09 to 6.2.1 does make serious problems

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

PostgreSQL version : 6.2.1

Compiler used : gcc

Hardware:
- ---------
Sparc 3000

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


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

Problem Description:
- --------------------
Hi,

due to a problem with the 1.09 version of the server I'd like
to upgrade to 6.2.1. Unfortunately I have problems with
"text" fields. Loading of fields of the type name, varchar and
text has beed done with psql, but when I do a select statement
all the texts are not in the database.

Regards,

Steffen Krug

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

Test Case:
- ----------
Install 6.2.1 on a Sun


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

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


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

From scrappy
Date: Tue, 11 Nov 1997 05:57:40 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: tuples with a size greater than 8145 K kill the database

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


Your name : Steffen Krug
Your email address : steffen.krug@usa.net

Category : runtime: back-end
Severity : critical

Summary: tuples with a size greater than 8145 K kill the database

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

PostgreSQL version : 1.09

Compiler used : gcc

Hardware:
- ---------
Sparc 3000

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


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

Problem Description:
- --------------------
Hi,

tupes with a size greater than 8145 Byte kill my database.
The whole directory in data/base is lost and I need to run
fsck to correct the problem.

I tried to unload the db and to create it new, but this does
not help anyway.

Please help!!! Upgrading to 6.2.1 is impossible, because
it did not run on my machine also.

Regards,

Steffen Krug


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

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


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

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


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

From scrappy
Date: Tue, 11 Nov 1997 09:04:55 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: PQntuples returns 0 when it shouldn't

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


Your name : Mark Middlemist
Your email address : 106262.1351@compuserve.co.uk

Category : runtime: front-end: C++
Severity : serious

Summary: PQntuples returns 0 when it shouldn't

System Configuration
- --------------------
Operating System : Linux 2.0.30 ELF (Slackware v.3.3)

PostgreSQL version : 6.2.1

Compiler used : gcc 2.7.2.2

Hardware:
- ---------
Cyrix K6? 80Mb RAM, 4G HardDrive

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


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

Problem Description:
- --------------------
When using PQntuplues (libPQ) I always got it returning 0
when it should have been returning greater values.

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

Test Case:
- ----------
Use libPQ to select data from a table where it is known at
least one item will be returned and call PQntuples on the result.

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

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


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

From scrappy
Date: Wed, 12 Nov 1997 13:15:26 +0000
From: Dr Stephen Henson <shenson@bigfoot.com>
Subject: Re: [PORTS] Problems with SCO.

Dr Stephen Henson wrote:
I've got a bit further. The problem with trigger appears to be caused by
the create_function_1 test. The first few lines of output read:

QUERY: CREATE FUNCTION widget_in(opaque)
RETURNS widget
AS
'/u/postgres/postgresql-6.2.1/src/test/regress/input/../regress.so'
LANGUAGE 'c';
NOTICE:ProcedureCreate: type 'widget' is not yet defined
FATAL 1:btree: items are out of order (leftmost 0, stack 1, update 1)
I'm still not sure what was causing this. However I updated my version
of gcc (I was using an older version) to 2.7.2.1 did a complete rebuild
(including zapping the db directory and running initdb again) and all
seems OK now. It passes almost all the regression tests (except for
error message differences, fp differences etc.).

The older version of gcc identified itself (gcc -v) as 2.7-95q4.

Now I can try to do something serious with it.

Steve.

From scrappy
Date: Wed, 12 Nov 1997 15:07:21 +0100
From: Tamas Laufer <lt660@ipisun.jpte.hu>
Subject: Bug Fix to aggregate evaluation

- ----Bug descr.
The backend crashes (causing a SIGSEGV) at computing *any* aggregate
function applied to an expression containing only a single function
- -expression, e.g. avg(float8(an_int4_field)).

- ----Platform
Any platform.

- ----Immediate cause
Write to *(NULL) in file ./src/backend/executor/functions.c by function
postquel_function(...).

- ----Proper cause
In file ./src/backend/executor/nodeAgg.c the function ExecAgg supposes
that the funct. ExecEvalExpr ( ? and all the ExecXXX family ? ) in
./src/backend/executor/execQual.c
is able to handle the case where isDone == NULL.

- ----Test case
From the psql frontend do the following:
create table xxx (i int4, f float8);
insert into xxx values(1, 1.0);

select avg(float8(i)) from xxx;
- --Here is the crash.
select sum(float4(i)) from xxx;
- --Here too.
select count(int4(f)) from xxx;
- --It's a crash too.
- --The following will not crash because it becomes an operator
- --expression:
select avg(1.0*float8(i)) from xxx;


- ----Solution
Edit the file
./src/backend/executor/nodeAgg.c
1.)Find the definition of function ExecAgg(Agg * node).
2.)insert a new definition (declaration) before the first executable
statement;
bool isDummyDone;
3.)Find the next "ExecEvalExpr" call.
newVal = ExecEvalExpr(.........,NULL);
4.)Here, replace "NULL" with "&isDummyDone".
Then recompile and reinstall the postgreSql.

- ----Explanation
Let we see the following sequence of calls at the aggregate evaluation
in the crashing test cases:

ExecAgg(...) defined in nodeAgg.c
ExecEvalExpr(...,isDone==NULL);
ExecEvalExpr(...,bool * isDone) defined in execQual.c
ExecEvalFunc(...,isDone==NULL);
ExecEvalFunc(... ,bool *isDone) defined in execQual.c
ExecMakeFunctionResult(....isDone==NULL);
ExecMakeFunctionResult(...,bool * isDone) defined in execQual.c
postquel_function(...,isDone==NULL);
postquel_function(...,bool * isDone) defined in functions.c
*isDone=true; /* without examinig the case isDone==NULL */

- ----Note
It would be a more acceptable solution to include
bool isDummyDone=false;
and
if (!isDone) isDone=&isDummyDone;
into any "ExecXXX(...,bool *isDone)" function definition.


Best regards,
Tamas
_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

From scrappy
Date: Wed, 12 Nov 1997 15:07:21 +0100
From: Tamas Laufer <lt660@ipisun.jpte.hu>
Subject: Bug Fix to aggregate evaluation

- ----Bug descr.
The backend crashes (causing a SIGSEGV) at computing *any* aggregate
function applied to an expression containing only a single function
- -expression, e.g. avg(float8(an_int4_field)).

- ----Platform
Any platform.

- ----Immediate cause
Write to *(NULL) in file ./src/backend/executor/functions.c by function
postquel_function(...).

- ----Proper cause
In file ./src/backend/executor/nodeAgg.c the function ExecAgg supposes
that the funct. ExecEvalExpr ( ? and all the ExecXXX family ? ) in
./src/backend/executor/execQual.c
is able to handle the case where isDone == NULL.

- ----Test case
From the psql frontend do the following:
create table xxx (i int4, f float8);
insert into xxx values(1, 1.0);

select avg(float8(i)) from xxx;
- --Here is the crash.
select sum(float4(i)) from xxx;
- --Here too.
select count(int4(f)) from xxx;
- --It's a crash too.
- --The following will not crash because it becomes an operator
- --expression:
select avg(1.0*float8(i)) from xxx;


- ----Solution
Edit the file
./src/backend/executor/nodeAgg.c
1.)Find the definition of function ExecAgg(Agg * node).
2.)insert a new definition (declaration) before the first executable
statement;
bool isDummyDone;
3.)Find the next "ExecEvalExpr" call.
newVal = ExecEvalExpr(.........,NULL);
4.)Here, replace "NULL" with "&isDummyDone".
Then recompile and reinstall the postgreSql.

- ----Explanation
Let we see the following sequence of calls at the aggregate evaluation
in the crashing test cases:

ExecAgg(...) defined in nodeAgg.c
ExecEvalExpr(...,isDone==NULL);
ExecEvalExpr(...,bool * isDone) defined in execQual.c
ExecEvalFunc(...,isDone==NULL);
ExecEvalFunc(... ,bool *isDone) defined in execQual.c
ExecMakeFunctionResult(....isDone==NULL);
ExecMakeFunctionResult(...,bool * isDone) defined in execQual.c
postquel_function(...,isDone==NULL);
postquel_function(...,bool * isDone) defined in functions.c
*isDone=true; /* without examinig the case isDone==NULL */

- ----Note
It would be a more acceptable solution to include
bool isDummyDone=false;
and
if (!isDone) isDone=&isDummyDone;
into any "ExecXXX(...,bool *isDone)" function definition.


Best regards,
Tamas
_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

From scrappy
Date: Wed, 12 Nov 1997 11:59:48 -0600 (CST)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Subject: Re: [BUGS] PostGreSQL Alpha Question
On Fri, 7 Nov 1997, Kenji T. Hollis wrote:

Hello all.

I'm not sure where to post this type of question, as I'm not sure if it's
a bug or user error on my part. However, I will ask in these three
mailing lists.

I have an Alpha PC164 533MHz machine, and I am trying to get PostGreSQL
6.2.1 to compile here. In order to do so, I have to comment out the
following entries in alpha.h and linux.h in src/include/port:
I too have been trying to get my UDB to run pgsql for sometime. It
appears that there are at least a handful of problems with pgsql and
Linux/Alpha. The s_lock problem is relativly easy to solve. The problem
that occurs during the running of initdb is much, much more tricky to
track down. If you will look in the archives for the ports list, there
has been an ongoing disscussion on this subject.
In order to solve the initdb problem, one is going to have do a
step by step debug of that process around the point where the problem is
occuring. This is only further complicated that what initdb does is one of
the most complex parts of the entire database.
You probably already noticed that a core gets generated when
initdb fails. This is a core dump from postgres itself, but running gdb on
postgres and the core gets one absolutely no information. It appears that
the program is getting very, very lost before it crashes. There is not
even a call stack to examin(sp?)!
I plan to go through initdb step by step and track down where this
problem is, but it will not be until mid December at the earlist, as life
is too busy to mess with it at the moment.
If you want to go ahead and try and find this bug yourself, you
are free to do so. :) But in the meantime, Pgsql and Linux/Alpha is not a
valid option, sorry.

PS> Could some one repost the s_lock patch fix. I seemed to have
missed it. 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: Thu, 13 Nov 1997 14:44:22 +1100
From: Philip Rhoades <philr@mail.austasia.net>
Subject: Error copying from large delimited text file?

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

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



Your name : Philip Rhoades
Your email address : philr@mail.austasia.ne


System Configuration
- ---------------------
Architecture (example: Intel Pentium) : dual Pent Pro

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

PostgreSQL version (example: PostgreSQL-6.1) : PostgreSQL-6.1.1

Compiler used (example: gcc 2.7.2) : gcc 2.7.2.1


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

Copying from a large '|' delimited text file works fine for small files
(~850K) but crashes out on large files (~34M). PG incorrectly complains
about a bad date field (ISO type) but I can tell from grepping the file
that the date fields are OK - it is getting confused with a following field
with initials in it ("TR").



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

The problem occurs every time I try to do a copy but creates tables of
different sizes each time so the problem surfaces on a different "TR" field
each time.



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



Philip Rhoades
Pricom Pty Ltd
http://www.pricom.com.au = http://203.12.131.20
GPO Box 3411 Sydney NSW 2001 Australia
Ph: +61:0411:185652
Fax: +61:2:9959-3481
E-mail: philr@mail.austasia.net

From scrappy
Date: Thu, 13 Nov 1997 09:40:49 +0000 ()
From: "Kenji T. Hollis" <khollis@Gawain.Houston-InterWeb.COM>
Subject: Re: [BUGS] PostGreSQL Alpha Question

I have totally given up on any hope of using PostGreSQL on my Alpha. I
have resorted to using MySQL. I had to install LinuxThreads 0.6, but
after I did that, it worked without a hitch.

Just to let you guys know of my plight with PostGres. I'm not saying I
hate PostGreSQL. I like it, and I use it in place of mysql or anything
else wherever possible. This was simply one of those cases where it was
not possible to avoid using it.

- -- Ken
- ------
===========================================================================
Houston Interweb Design, Inc. || Borland C++Builder, Gnu C++,
Programmer and Sys/Net Admin || Perl 5, Pascal, and Linux to go
C/C++/Perl/HTML/CGI/GUI || (With a side of fries, please)
===========================================================================
Crash a Pentium today! Dial: F0 0F C7 C8! Operators standing by!

From scrappy
Date: Thu, 13 Nov 1997 14:05:21 -0500
From: infotech@discovernet.net (Richard Spangerberg)
Subject: In Response to your recent E-Mail Request on unsuccessful Installs

I was unable to install PostgreSQL on a Dec/Alpha OSF1 Version 3.2 machine.
After trying for a while I found out that it was ported to Version 4.0 but
had not been ported to 3.2.

The subject of threads support came up and it became obvious that the
current PostgreSQL was not going to work without writing a new port to
address the threads issue. I have additional information if you wish more.

Richard Spangenberg
InfoTech, Inc.
infotech@discovernet.net

From scrappy
Date: Thu, 13 Nov 1997 15:09:44 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: moving from 6.1(solaris Sparc) to 6.2 (Solaris x86) breaks the database

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


Your name : Wayne Huling
Your email address : wayne@smb.larc.nasa.gov

Category : runtime: back-end
Severity : critical

Summary: moving from 6.1(solaris Sparc) to 6.2 (Solaris x86) breaks the database

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

PostgreSQL version : 6.2.1

Compiler used : gcc version 2.7.2.3

Hardware:
- ---------
Pentium 200, 64MB

SunOS sd 5.6 Generic i86pc i386 i86pc


Versions of other tools:
- ------------------------
GNU Make version 3.76.1
flex version 2.5.4


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

Problem Description:
- --------------------
I use the pg_dumpall from the new version. No errors or
anything are reported when I query the information that is
there, but when I add information to the tables the insert
comes back fine. Then where I select from the database next
all hell breaks loose. The laod average shoots, disk goes nuts
and I have to turn the machine off to reboot it.

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

Test Case:
- ----------
Putting my tables in from 6.1 and then inserting anything
into the database.

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

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


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

From scrappy
Date: Fri, 14 Nov 1997 00:30:33 +0200
From: Lasse =?iso-8859-1?Q?Hiller=F8e?= Petersen <lassehp@imv.aau.dk>
Subject: Installing pgsql on IRIX 6.4 = problem

I had installed 6.1 without much trouble, but while trying to install the
latest DBD::Pg, I found it to be wanting 6.2.x. I was planning on
installing it anyway, so I went ahead.

Alas, the IRIX-FAQ for installing Postgresql has not been updated to match
pgsql-6.2.1_3, and the things mentioned in it don't seem to have been
rolled into the distribution. Further, the backend/parser/scan.l uses some
code (xc) which makes IRIX lex choke, yet the configure doesn't complain
that it now requires flex. (I presume the things in scan.l are
flex-specific.)

After installing flex and adding the MK_NO_LORDER=true to
makefiles/Makefile.irix5 the gmake succeeds, and I can install.

Alas when running initdb, I get a segment violation. From dbx:
dbx /usr/local/pgsql/bin/postgres
dbx version 7.1 Dec 3 1996 17:03:19

PC value from core file (0x10169e14) is not part of the program.
Assuming return register value (0x10169e14) usable to locate PC.
Core from signal SIGSEGV: Segmentation violation
(dbx) (dbx) where
0 AllocSetInit(0x101aca54, 0x101e44d0, 0x486dc, 0x101e44d4, 0x101e44d0,
0x1, 0x1, 0x100564ec)
["/disk04/software/PSQL/postgresql-6.2.1/src/backend/utils/mmgr/aset.c":116, 0x1
0169e14]
1 OrderedElemPushInto(0x101aca54, 0x101e44d0, 0x486dc, 0x101e44d4,
0x101e44d0, 0x1, 0x1, 0x100564ec)
["/disk04/software/PSQL/postgresql-6.2.1/src/backend/utils/mmgr/oset.c":147, 0x1
016c3fc]
2 EnableMemoryContext(0x101aca54, 0x0, 0x486dc, 0x101e44d4, 0x101e44d0,
0x1, 0x1, 0x100564ec)
["/disk04/software/PSQL/postgresql-6.2.1/src/backend/utils/mmgr/mcxt.c":169, 0x1
016a3e0]
3 InitPostgres(0x7fff3030, 0x0, 0x486dc, 0x101e44d4, 0x101e44d0, 0x1,
0x1, 0x100564ec)
["/disk04/software/PSQL/postgresql-6.2.1/src/backend/utils/init/postinit.c":544,
0x10169b3c]
4 BootstrapMain(0x6, 0x7fff2f48, 0x0, 0xffffffff, 0xffffffff, 0x1, 0x0,
0x0)
["/disk04/software/PSQL/postgresql-6.2.1/src/backend/bootstrap/bootstrap.c":415,
0x10056724]
5 main(0x7, 0x7fff2f44, 0x486dc, 0x101e44d4, 0x101e44d0, 0x1, 0x1,
0x100564ec)
["/disk04/software/PSQL/postgresql-6.2.1/src/backend/main/main.c":74,
0x1009f504]
6 __start()
["/xlv22/ficus-jan23/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":166,
0x10021f78]

At this point, I am starting to feel lost.

Anyone had success installing pgsql on IRIX 6.4 and care to share some hints?

$ uname -a
IRIX64 imv 6.4 02121744 IP27

Machine is SGI Origin200.

- -Lasse

From scrappy
Date: Fri, 14 Nov 1997 10:59:12 GMT
From: Andrew Martin <martin@biochemistry.ucl.ac.uk>
Subject: Re: [PORTS] Installing pgsql on IRIX 6.4 = problem
I had installed 6.1 without much trouble, but while trying to install the
latest DBD::Pg, I found it to be wanting 6.2.x. I was planning on
installing it anyway, so I went ahead.

Alas, the IRIX-FAQ for installing Postgresql has not been updated to match
pgsql-6.2.1_3, and the things mentioned in it don't seem to have been
rolled into the distribution. Further, the backend/parser/scan.l uses some
code (xc) which makes IRIX lex choke, yet the configure doesn't complain
that it now requires flex. (I presume the things in scan.l are
flex-specific.)
Sorry, have been too busy *using* PostgreSQL to get around to installing
6.2 under Irix 6.x !

I have lept my Indy on Irix 5.3 for the moment (to our system manager's
annoyance), as I don't have time to play around with getting it to work
under Irix 6. When things quieten down a bit, I'll see what I can do.

If anyone can give me a recipe for installing under Irix 6, I'll gladly
put it in the FAQ


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: Sat, 15 Nov 1997 13:43:43 -0500 (EST)
From: post gre <postgres@pgg.quintessential.com>
Subject: failed to compile

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 : Gypsy Rogers
Your email address : Gypsy@FreeQ.com


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

Operating System (example: Linux 2.0.26 ELF) : FreeBSD 2.1.7.1-RELEASE

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

Compiler used (example: gcc 2.7.2) : gcc 2.6.3


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

When following your steps to the letter it gets errors on a make all.

The following is the make.log



/usr/local/bin/gmake -C lextest all
gmake[1]: Entering directory `/usr/src/postgresql-6.2.1/src/lextest'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/src/postgresql-6.2.1/src/lextest'
/usr/local/bin/gmake -C utils all
gmake[1]: Entering directory `/usr/src/postgresql-6.2.1/src/utils'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/usr/src/postgresql-6.2.1/src/utils'
/usr/local/bin/gmake -C backend all
gmake[1]: Entering directory `/usr/src/postgresql-6.2.1/src/backend'
/usr/local/bin/gmake -C access all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access'
/usr/local/bin/gmake -C common SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/common'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/common'
/usr/local/bin/gmake -C gist SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/gist'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/gist'
/usr/local/bin/gmake -C hash SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/hash'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/hash'
/usr/local/bin/gmake -C heap SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/heap'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/heap'
/usr/local/bin/gmake -C index SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/index'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/index'
/usr/local/bin/gmake -C rtree SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/rtree'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/rtree'
/usr/local/bin/gmake -C nbtree SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/nbtree'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/nbtree'
/usr/local/bin/gmake -C transam SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/access/transam'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access/transam'
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/access'
/usr/local/bin/gmake -C bootstrap all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/bootstrap'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/bootstrap'
/usr/local/bin/gmake -C catalog all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/catalog'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/catalog'
/usr/local/bin/gmake -C commands all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/commands'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/commands'
/usr/local/bin/gmake -C executor all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/executor'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/executor'
/usr/local/bin/gmake -C lib all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/lib'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/lib'
/usr/local/bin/gmake -C libpq all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/libpq'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/libpq'
/usr/local/bin/gmake -C main all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/main'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/main'
/usr/local/bin/gmake -C nodes all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/nodes'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/nodes'
/usr/local/bin/gmake -C optimizer all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/optimizer'
/usr/local/bin/gmake -C path SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/path'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/path'
/usr/local/bin/gmake -C plan SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/plan'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/plan'
/usr/local/bin/gmake -C prep SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/prep'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/prep'
/usr/local/bin/gmake -C util SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/util'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/util'
/usr/local/bin/gmake -C geqo SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/geqo'
gmake[3]: `SUBSYS.o' is up to date.
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/optimizer/geqo'
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/optimizer'
/usr/local/bin/gmake -C parser all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/parser'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/parser'
/usr/local/bin/gmake -C port all PORTNAME=BSD44_derived
gmake[2]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/port'
/usr/local/bin/gmake -C BSD44_derived SUBSYS.o
gmake[3]: Entering directory `/usr/src/postgresql-6.2.1/src/backend/port/BSD44_derived'
gcc -I../../../include -I/usr/local/include -O2 -m486 -pipe -Wall -Wmissing-prototypes -DBSD44_derived -I../.. -I../../../include -c dl.c
In file included from dl.c:42:
/usr/include/dlfcn.h:41: conflicting types for `dlopen'
/usr/include/link.h:187: previous declaration of `dlopen'
/usr/include/dlfcn.h:42: conflicting types for `dlsym'
/usr/include/link.h:189: previous declaration of `dlsym'
gmake[3]: *** [dl.o] Error 1
gmake[3]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/port/BSD44_derived'
gmake[2]: *** [submake] Error 2
gmake[2]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend/port'
gmake[1]: *** [port.dir] Error 2
gmake[1]: Leaving directory `/usr/src/postgresql-6.2.1/src/backend'
gmake: *** [all] Error 2

From scrappy
Date: Sat, 15 Nov 1997 20:49:26 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: the rpm gave me a note that said it had a dependiency it could not resolve.

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


Your name : Joe Dieckert
Your email address : dieckert@degaco.com

Category : unknown
Severity : critical

Summary: the rpm gave me a note that said it had a dependiency it could not resolve.

System Configuration
- --------------------
Operating System : Linux Redhat 6.2

PostgreSQL version : 6.0

Compiler used : RPM

Hardware:
- ---------
Pentium 120, 32Meg Ram


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


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

Problem Description:
- --------------------
Ran rpm -Uvh postgresql-6_2-3_i386.rpm

two messages said dependency on /bin/sh

package would not install.

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

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


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

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


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

From scrappy
Date: Sun, 16 Nov 1997 19:24:03 -0600 (CST)
From: Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>
Subject: Re: [BUGS] PostGreSQL Alpha Question
On Thu, 13 Nov 1997, Kenji T. Hollis wrote:

I have totally given up on any hope of using PostGreSQL on my Alpha. I
have resorted to using MySQL. I had to install LinuxThreads 0.6, but
after I did that, it worked without a hitch.
Glad to know you found a working, if not optimal solution.
Just to let you guys know of my plight with PostGres. I'm not saying I
hate PostGreSQL. I like it, and I use it in place of mysql or anything
else wherever possible. This was simply one of those cases where it was
not possible to avoid using it.
Hopefully I will get pgsql running on Linux/Alpha by the New Year,
and then you will be able to use your first choice. :) Talk to you later.

- ----------------------------------------------------------------------------
"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, 17 Nov 1997 08:00:18 -0600
From: Mark Martin <wolf@bescape.com>
Subject: FYI -- PGSQL 6.2.1 and GLIBC

There appears to be a bug in glibc in the readline functions.
Everything compiled fine on my RedHat system, and postmaster runs well
(the regression tests ran mostly ok), but psql core dumps on a
segmentation fault when I just try to run it interactively. gdb reports
the fault deep within glibc.so...

I also noticed the regression tests failed on time/date stuff (they did
when I ran 6.2 before), but now also fail "int2" and "int4" of all
things. I checked the .out files, and the parser is whining about when
a "3.45" is inserted, it had problems with the ".45". And when it
inserted a VERY large value, like "100000000", it whined about that
too. I suspect there are problems in vscanf too...

My suggestion is not to use glibc (and linuxthreads and crypt) yet. I'm
going to try to recompile the glibc-snapshot and give that a shot.

Mark
- --
http://www.bescape.com
Homesite for Incarnate -- The ultimate online roleplaying universe
From scrappy
Date: Tue, 18 Nov 1997 20:38:32 +0100
From: Tamas Laufer <lt660@ipisun.jpte.hu>
Subject: btree index creation bug with a possible temp. work-around

Platform
SCO3.2v5.0.2, SCO native cc, GNU make, flex and bison.

- ------Bug description
Indexing a non-empty relation created by

create table xxx (i int4, f float8);
insert into xxx values(0,0.0);
insert into xxx values(1,1.0);
.............................
insert into xxx values(4998,4998.0);
insert into xxx values(4999,4999.0);
create unique index xxxbi on xxx using btree (i);

executes seemingly normally.
But the resulted index is wrong because
1.) select count(*) from xxx where xxx.i>=30
results 2690 instead of 4970,
2.) vacuum complains about "number of index tuples" in xxxbi.

When the table creation is immediately followed by the index-creation
i.e. we insert the tuples into an empty index the resulted index will
be errorfree.

- ------Temporary work-around
Forbid the use of sort/build by defining FastBuild=false for
btbuild(...) in nbtree.c.
The "create index" for btrees will be slightly slower than it was before
but the resulted btree indexes will be usable.

Regards,
Tamas
_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

From scrappy
Date: Wed, 19 Nov 1997 11:39:44 MET-1MEST
From: "Vegard Bakke" <Vegard.Bakke@hibu.no>
Subject: Problem with srandom in v6.1 on HP-UX 10.10

I'm useing
flex 2.5.4,
GNU make 3.76.1
gcc 2.7.2

When I compile I get the following error:
gcc -I../../include -Wall -Wmissing-prototypes -Dhpux -I.. -I../port/hpux -I../../include -c async.c -o async.o
In file included from async.c:85:
../port/hpux/port-protos.h:31: conflicting types for `srandom'
/opt/local/lib/gcc-lib/hppa1.1-hp-hpux10.10/2.7.2.1/include/stdlib.h:265: previous declaration of `srandom'


- -----------------------------------
'./backend/port/hpux/port-protos.h'
Line 31:
extern void srandom(int seed);

'./backend/port/hpux/port.c'
Line 39:
void srandom(int seed)
{
srand48((long int) seed);
}
- -----------------------------------
'man 3 srandom':
void srandom(unsigned seed);
- -----------------------------------


There are different types of the parameter (int / unsigned)?
Is the solution comment the PostgreSQL version of srandom,
or to change it to unsigned? What are the consequenses of these
options?
Are ther any better way around problems like this?


Thanks in advance...

Vegard



- --
Vegard Bakke
vegard.bakke@hibu.no
Kirkegata 9, 3600 Kongsberg, Norway

My spelling is Wobbly. It's good spelling, but it Wobbles, and
the letters get in the wrong places. -- Winnie the Pooh

From scrappy
Date: Thu, 20 Nov 1997 09:04:33 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: function yy_flush_buffer() undefined at link of backend

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


Your name : Rachel Street
Your email address : R.K.Street@rl.ac.uk

Category : install: other
Severity : non-critical

Summary: function yy_flush_buffer() undefined at link of backend

System Configuration
- --------------------
Operating System : DEC UNIX OSF V4.0b

PostgreSQL version : 6.2

Compiler used : native cc

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


Versions of other tools:
- ------------------------
GNU Make version 3.74
cc, flex and yacc from base OS

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

Problem Description:
- --------------------
backend/parser.scan.l contains yy_flush_buffer I think
This function is not linked in by default (I tried adding -ly)
I got no reply from the other list and could do with some answer please
If the software is supposed to work on OSF; which versions have actually worked
and how do I get it to compile ?

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

Test Case:
- ----------
tar -xvf /tmp/postgresql-6.2.tar
cd postgres-6.2
./configure
gmake

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

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


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

From scrappy
Date: Thu, 20 Nov 1997 15:23:51 +0000
From: Frank Ihringer <fihringe@telemation.de>
Subject: Symbol CurrentTriggerData not found

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

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



Your name : Frank Ihringer
Your email address : ihringe@telemation.de


System Configuration
- ---------------------
Architecture (example: Intel Pentium) :Sun Sparc 20

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

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

Compiler used (example: gcc 2.7.2) :gcc 2.7.1

Please enter a FULL description of your problem:
- ------------------------------------------------
The program compiles ok (with minor modification of include-order for
"port-protos.h" in port.c at "/src/backend/port/sparc_solaris")and most
of the regress-test are also ok.

The error happens with all tests (i.e. triggers, create_function_2,
select_views, and misc) who try to use the function or label "Current
TriggerData" expected in refint.so or regress.so:

ErrorMessages (from triggers.out) :
QUERY: insert into fkeys2 values (10, '1', 1);
WARN:Load of file
/export/home/frank/test/postgresql-6.2.1/src/test/regress/input/../../../../contrib/spi/refint.so
failed: ld.so.1: /usr/local/bin/postgres: fatal: relocation error:
symbol not found: CurrentTriggerData: referenced in
/export/home/frank/test/postgresql-6.2.1/src/test/regress/input/../../../../contrib/spi/refint.so

or

QUERY: insert into dup17 values (17);
WARN:Load of file
/export/home/frank/test/postgresql-6.2.1/src/test/regress/input/../regress.so
failed: ld.so.1: /usr/local/bin/postgres: fatal: relocation error:
symbol not found: CurrentTriggerData: referenced in
/export/home/frank/test/postgresql-6.2.1/src/test/regress/input/../regress.so



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

From scrappy
Date: Thu, 20 Nov 1997 11:04:53 -0600
From: Blake McBride <blake@edge.net>
Subject: Postgres for Windows 95/NT?

Hello,

Could you please tell me if anyone is working on
a port of Postgres to Windows 95 & NT?

Thanks.

- --blake


- --
Download source code to my Dynace Object Oriented
Extension to C and Windows Development System from:
http://www.edge.net/algorithms
Blake McBride (blake@edge.net)
Algorithms Corporation - 615-791-1636 - USA

From scrappy
Date: Thu, 20 Nov 1997 15:39:54 -0600 (CST)
From: Gary Huckabay <gary@rattler.cameron.edu>
Subject: postgress

Postgress v6.2.1
Slackware v3.2, Linux 2.0.32-pre5
Intel Pentium Pro, 200 MHz, 32 MRAM

Installation was fairly smooth but two tests (horology, misc) failed. If
you're interested in the regression log, I'll be glad to send you a copy.

Gary
- ----------------------------------------------------------------------------
gary@rattler.cameron.edu http://rattler.cameron.edu/

From scrappy
Date: Thu, 20 Nov 1997 20:12:57 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: "CREATE DATABASE" doesn't populate pg_database table

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


Your name : David Myers
Your email address : david.myers@corp.sun.com

Category : runtime: back-end
Severity : critical

Summary: "CREATE DATABASE" doesn't populate pg_database table

System Configuration
- --------------------
Operating System : Solaris 2.5.1/Sparc

PostgreSQL version : 6.2.1

Compiler used : gcc

Hardware:
- ---------
SunOS concord 5.5.1 Generic_103640-08 sun4m sparc SUNW,SPARCstation-5


Versions of other tools:
- ------------------------
gmake, lex (I believe)

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

Problem Description:
- --------------------
Doing either:

createdb <dbname> -or -
CREATE DATABASE <dbname>

fails to populate the relevant fields in the pg_database
table. Blank entries instead are created. So, when you
do psql <dbname>, you get a message saying the database
doesn't exist. The entry for template1, however, is
filled in correctly.


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

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


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

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


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

From scrappy
Date: Thu, 20 Nov 1997 20:50:56 +0000
From: Dr Stephen Henson <shenson@bigfoot.com>
Subject: Re: [PORTS] Symbol CurrentTriggerData not found

I've had this problem with SCO. The actual symbols reported are in the
postgres binary but are not exported by default. Adding:

LDFLAGS += -Wl,-Bexport -Wl,-dy

to Makefile.port worked for me.

Steve.

From scrappy
Date: Fri, 21 Nov 1997 05:18:36 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: backends/parser/scan.l contains yy_flush_buffer

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


Your name : Rachel Street
Your email address : R.K.Street@rl.ac.uk

Category : install: compile
Severity : non-critical

Summary: backends/parser/scan.l contains yy_flush_buffer

System Configuration
- --------------------
Operating System : Digital Alpha Osf V4.0b

PostgreSQL version : 6.2.1

Compiler used : Native cc

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


Versions of other tools:
- ------------------------
GNU Make version 3.74
flex version 2.5.4 (GNU not cc)

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

Problem Description:
- --------------------
Native flex processing of backends/parser/scan.l leaves yy_flush_buffer() which cannot be linked


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

Test Case:
- ----------
./configure
gmake

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

Solution:
- ---------
Use GNU flex not native flex on DEC Alpha running V4.0b

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

From scrappy
Date: Fri, 21 Nov 1997 10:29:00 +0000
From: Rachel Kay Street <Rachel.K.Street@rl.ac.uk>
Subject: PostgreSQL V2.6.1 testing fails

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 : Rachel Street
Your email address : R.K.Street@rl.ac.uk


System Configuration
- ---------------------
Architecture (example: Intel Pentium) : Digital 3000 Alpha
300LX

Operating System (example: Linux 2.0.26 ELF) : OSF V4.0b

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

Compiler used (example: gcc 2.7.2) : Native cc


Please enter a FULL description of your problem:
- ------------------------------------------------
regress test fail to run properly
gmake all runtest


Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------
gmake all runtest
.
.
.
=============== destroying old regression database... =================
E_DU3190_BAD_LKINIT
Couldn't initialize the locking system for this process.
Status returned was, 0x00000001.
Please insure that the process is properly installed and that
you have sufficient privilege and system resources to
invoke it
.

Destruction of database '' abnormally terminated.
=============== creating new regression database... =================
Creating database 'regression' . . .

E_DU3190_BAD_LKINIT
Couldn't initialize the locking system for this process.
Status returned was, 0x00000001.
Please insure that the process is properly installed and that
you have sufficient privilege and system resources to
invoke it
.
Creation of database 'regression' abnormally terminated.
createdb failed


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


Rachel Street
- --
****************************************************************
* R K Street - RAL Database Systems - (01235) 821900 ext 5833 *
* Rutherford Appleton Laboratory, Chilton, DIDCOT, Oxon, UK *
* Email: TCPIP street@wdcc1.bnsc.rl.ac.uk *
* or R.K.Street@rl.ac.uk *
* DECNET wdcc1b::street *
****************************************************************

From scrappy
Date: Fri, 21 Nov 1997 15:38:11 -0000 (GMT)
From: R.K.Street@rl.ac.uk
Subject: FW: PostgreSQL V2.6.1 testing fails

- -----FW: <3475626C.41C6@rl.ac.uk>-----

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 : Rachel Street
Your email address : R.K.Street@rl.ac.uk


System Configuration
- ---------------------
Architecture (example: Intel Pentium) : Digital 3000 Alpha
300LX

Operating System (example: Linux 2.0.26 ELF) : OSF V4.0b

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

Compiler used (example: gcc 2.7.2) : Native cc


Please enter a FULL description of your problem:
- ------------------------------------------------
regress test fail to run properly
gmake all runtest


Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
- ----------------------------------------------------------------------
gmake all runtest
.
.
.
=============== destroying old regression database... =================
E_DU3190_BAD_LKINIT
Couldn't initialize the locking system for this process.
Status returned was, 0x00000001.
Please insure that the process is properly installed and that
you have sufficient privilege and system resources to
invoke it
.

Destruction of database '' abnormally terminated.
=============== creating new regression database... =================
Creating database 'regression' . . .

E_DU3190_BAD_LKINIT
Couldn't initialize the locking system for this process.
Status returned was, 0x00000001.
Please insure that the process is properly installed and that
you have sufficient privilege and system resources to
invoke it
.
Creation of database 'regression' abnormally terminated.
createdb failed


If you know how this problem might be fixed, list the solution below:
- ---------------------------------------------------------------------
My fault. INGRES and PostgreSQL getting confussed with each other.


Rachel Street

PS
I needed to do the following as well (after configure had been run):
I just changed the
#define HAVE_INT_TIMEZONE 1
line in include/config.h to
/* #undef HAVE_INT_TIMEZONE */
Rachel

********************************************************************
* R K Street - RAL Database Systems - (01235) 821900 ext 5833 *
* Rutherford Appleton Laboratory, Chilton, DIDCOT, Oxon, UK *
* Email: TCPIP street@wdcc1.bnsc.rl.ac.uk or R.K.Street@rl.ac.uk *
********************************************************************

From scrappy
Date: Fri, 21 Nov 1997 19:00:31 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Make fails missing file y.tab.c

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


Your name : Kevin Priest
Your email address : turkeyhill@greennet.net

Category : install: compile
Severity : critical

Summary: Make fails missing file y.tab.c

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

PostgreSQL version : 6.1.2

Compiler used : gcc

Hardware:
- ---------
Sparc 20 64M

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

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

Problem Description:
- --------------------
Make fails missing file y.tab.c

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

Test Case:
- ----------
download tar file.
extract
run configure
run gmake

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

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


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

From scrappy
Date: Sat, 22 Nov 1997 15:44:41 +-100
From: tjoen <tjoen@dds.nl>
Subject: RE: [PORTS] Postgres for Windows 95/NT?
Could you please tell me if anyone is working on
From scrappy
Date: Wed, 23 Jul 1997 12:23:23 -0500
From: Al_Dev@candle.com
Subject: [PORTS] Postgresql 6.1 on Windows NT/ Windows 95

Question: Port to NT==> Did anybody try to compile postgresql61. using the
Softway for NT (unix on NT!!)? I heard they support everything including
gmake,gcc, g++, ipc, shared memory, sockets and what not!! But it costs few
bucks about $700 for 5 user license. Microsoft NT is a type of UNIX , it is
a flavor of UNIX!! (But it is slowest of all the unixes!!)
Softway is at : http://www.softway.com

I was trying to port/compile postgresql6.1 on Windows NT/95 on my home pc
but am having minor glitches. I got over most of them!! (I was trying for
the last 60 days <---). I am using the the gcc and gmake for win32 from
cygnus corp which is at -
http://www.cygnus.com/misc/gnu-win32
and program is cdk.exe (package gnu-win32)
From scrappy
Date: Sun, 04 May 1997 16:50:18 +0200
From: "Martin H. Ludwig" <Martin.H.Ludwig@rz.ruhr-uni-bochum.de>
Subject: Re: [PORTS] libpq ported to Win32!

Hello Ben!

I ported the libpq (and libqp++) to Win32 and Win16 using a "normal" compiler
(Watcom)
because using the cygnus gcc makes it difficult to interact with other
languages and programs not compiled with cygnus gcc (I needed access to
posgreSQL form a wxWindows (32-Bit) and a Visual-Basic (16-Bit) program.

Klaus-Dieter Meyer <klaus@kadeem.h.eunet.de> and I are interested in porting
the complete PostgreSQL to Win32. Using the cygwin.dll the port will be
easier than using an other compiler, but cygnus changed the license for
the cygwin.dll in 1997 making it not usable in a project with a commercial
touch. So I prefer not using the cygnus-gcc. The extra work will be the
socket access (Win-Sockets are not compatible with FILE*) and perhaps some
pipe- and I/O-functions (output to stderr/stdout in libpq for
From scrappy
Date: Fri, 2 May 1997 23:52:26 +1000 (EST)
From: Ben Elliston <bje@air.net.au>
Subject: [PORTS] libpq ported to Win32!

All,

I have managed to port libpq (not libpq++ yet) and some associated
utilities to Win32. I have compiled the "psql" monitor program and have
queried a PostgreSQL server on a Linux machine from a machine running
WinNT 4.0.

I'll explain what I've done, because I've been so pleased by the way it's
going. Cygnus have recently released a UNIX-hosted (and now native) gcc
for Win32 that includes a run-time UNIX emulation library called
"cygwin.dll". They provide an entire of /usr/include-like header files
that allow you to link against the cygwin DLL so that UNIX software can be
compiled natively onto Win32 without modification!

The only catch is that you must have the cygwin.dll file installed on the
machine, but I see this is a _minor_ irritation. The problem I am
currently facing is that most of the Postgres source includes a file in
its own source tree called "ipc.h" that #includes <sys/ipc.h> and Cygnus
haven't provided a SysV shared memory emulation yet. I will ask on the
Cygwin-32 mailing list and report back here.

As a demonstration of this stuff, people can pick up a copy of the DLL
(gzip'ed for bandwidth savings) and "psql.exe" from:

ftp://ftp.air.net.au/pub/postgres

libpq seems to have trouble determining the WinNT user name from the
environment (I may have to ask the Cygwin team about this), but for now,
it can be overcome by issuing "set PGUSER=<your-login-name>". Other than
that, psql works precisely as expected!
I would greatly appreciate it if anyone with access to a Postgres server
and a Windows machine could try out psql on:

WinNT 3.51 and 4.0
Windows 95
Windows 3.11 with the Win32s subsystem installed (fat chance)

From scrappy
Date: Sat, 26 Apr 1997 13:52:44 -0400 (EDT)
From: David Friend <dfriend@atlsci.atlsci.com>
Subject: Re: [PORTS] Win32 port
On Sat, 26 Apr 1997, Ben Elliston wrote:

Has anyone managed to port PortgreSQL to Win32? I see lots of conditional
code for Win32, but it's not listed as a supported platform in the
documentation.

If I have to attempt the port myself, is the stuff in the src/test/
directory sufficient to prove that it works? Are there more extensive
test suites out there that could be used?
Go to the hackers archives at
ftp://ftp.postgresql.org/pub/majordomo/pgsql-hackers-digest. Look for
messages I mailed on March 27 and April 12th. Look for a message from
Martin.H.Ludwig@rz.ruhr_uni_bachan.de on April 11th. (I forget who I was
replying to in March.)

Martin ported the libpq or libpq++ library (I forget which). He wants to
port the whole thing. The fellow from March (I assume he is a different
person) also wants to do a port. If the three of you got together, you
could start a sub-team to port the whole thing. I would suggest you start
with the client side, since the project would be much smaller and would be
useful even if you never finish the server side port.

From scrappy
Date: Fri, 11 Apr 1997 21:03:48 +0200
From: "Martin H. Ludwig" <Martin.H.Ludwig@rz.ruhr-uni-bochum.de>
Subject: [HACKERS] Win32-Port

Hello!

I need a lite version of PostgeSQL for use on a notebook with W95 to use the
same client-programs in the net as on the notebook.

Before trying a port I want to ask you, if anybody else is doing this port.
If yes, please tell me.

BTW, I complied the libpq and libpq++-code on w95 (a very quick hack), if
somebody is interested, feel free to mail me.

From scrappy
Date: Sun, 23 Nov 1997 20:12:51 +1100
From: "Geoffrey J. Crick" <gjcrick@aucom.com.au>
Subject: [none]

subscribe

From scrappy
Date: Sun, 23 Nov 1997 08:38:53 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: configure dies with configure: error: echo behaviour undetermined

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


Your name : Jochen Hoff
Your email address : jochen@duckhome.snafu.de

Category : install: other
Severity : critical

Summary: configure dies with configure: error: echo behaviour undetermined

System Configuration
- --------------------
Operating System : Linux linux-2.0.29

PostgreSQL version : postgresql-6.2.1

Compiler used : gcc 2.7.2.1

Hardware:
- ---------
Pentium 100 32 MB RAM
Linux duckhome.snafu.de 2.0.29 #3 Don Nov 6 12:11:54 MET 1997 i586 unknown



Versions of other tools:
- ------------------------
GNU Make version 3.76.1,
flex version 2.5.4
sh-utils-1.16

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

Problem Description:
- --------------------
configure reports

checking for install... /usr/local/bin/install
- - Using /usr/local/bin/install
./configure: test: integer expression expected before -eq
configure: error: echo behaviour undetermined

All of my answers to configure Questions was enter.
I think i have the newest gnu-things installed

Surely its only a Problem with my Devolpment of Programs and not a Problem of Postgres.




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

Test Case:
- ----------
./configure

in /usr/src/pgsql and you get it.

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

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


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

From scrappy
Date: Mon, 24 Nov 1997 11:44:36 +0100
From: "PC" <chris@power.fr>
Subject: error

Hello
I have a Kheops Linux installed on a DOS partition (I have a P133/16Mo/W95)
it's a french distrib based upon Slakware
on a CD I bought I tried to install Postgres but
it failed to compile, evrytime.
actually many exe-files failed to be created (monitor...)
there are some files which aren't found whereas I copy evrything
from postgres.
how can I perform the complete installation ?

From scrappy
Date: Mon, 24 Nov 1997 09:49:04 -0500 (EST)
From: bruc@bms.com (Robert Bruccoleri)
Subject: PostgreSQL on Irix 6

Gentlemen:
There is a really nasty loader bug in the compiler system (7.1)
on Irix 6.x, and the error that Lasse Petersen is the result of it.
Here is the original message. I don't know if all the changes have been
From scrappy
Date: Fri, 06 Jun 1997 17:12:20 -0400 (EDT)
From: bruc@bms.com (Robert Bruccoleri)
Subject: [PORTS] Patches for Irix 6.4

I have worked out how to compile PostgreSQL on Irix 6.4 using the -n32 compiler
mode and version 7.1 of the C compiler. (The n32 compiler use 32 bits addressing,
but allows access to all the instructions in the MIPS4 instruction set.)
There were several problems:

1) The ld command is not referenced as a macro in all the Makefiles. On
this platform, you have to include -n32 on all the ld commands. Makefiles
were changed as needed.

2) There is a bug in "ld" which mishandles the addresses of static procedures
when object files are assembled into larger object files using "ld -r".
Because of this, I put a hack into src/backend/Makefile to avoid all the
SUBSYS.o files and just link all the objects. I have contacted SGI about the
problem, and hopefully, it will be fixed in the near future.

3) Lots of warnings are generated from the compiler. Since the regression
tests worked OK, I didn't attempt to fix them. If anyone wants the compilation
log, please let me know, and I'll email it to you.

The version of postgresql was 970602. Here is Makefile.custom:

CUSTOM_COPT = -O2 -n32
MK_NO_LORDER = 1
LD = ld -n32
CC += -n32

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

Here are the patches:

*** ./backend/access/Makefile.orig Sun Nov 10 00:00:15 1996
- - --- ./backend/access/Makefile Tue Jun 3 10:22:32 1997
***************
*** 8,13 ****
- - --- 8,16 ----
#
#-------------------------------------------------------------------------

+ SRCDIR = ../..
+ include ../../Makefile.global
+
OBJS = common/SUBSYS.o gist/SUBSYS.o hash/SUBSYS.o heap/SUBSYS.o \
index/SUBSYS.o rtree/SUBSYS.o nbtree/SUBSYS.o transam/SUBSYS.o


*** ./backend/bootstrap/Makefile.orig Fri Apr 18 06:00:23 1997
- - --- ./backend/bootstrap/Makefile Tue Jun 3 10:23:59 1997
***************
*** 38,44 ****
all: SUBSYS.o

SUBSYS.o: $(OBJS)
! ld -r -o SUBSYS.o $(OBJS)

# bootstrap.o's dependency on bootstrap_tokens.h is computed by the
# make depend, but we state it here explicitly anyway because
- - --- 38,44 ----
all: SUBSYS.o

SUBSYS.o: $(OBJS)
! $(LD) -r -o SUBSYS.o $(OBJS)

# bootstrap.o's dependency on bootstrap_tokens.h is computed by the
# make depend, but we state it here explicitly anyway because

*** ./backend/Makefile.orig Thu May 22 00:00:15 1997
- - --- ./backend/Makefile Thu Jun 5 16:47:27 1997
***************
*** 54,60 ****
all: postgres $(POSTGRES_IMP) global1.bki.source local1_template1.bki.source

postgres: $(OBJS) ../utils/version.o
! $(CC) -o postgres $(OBJS) ../utils/version.o $(LDFLAGS)

$(OBJS): $(DIRS:%=%.dir)

- - --- 54,64 ----
all: postgres $(POSTGRES_IMP) global1.bki.source local1_template1.bki.source

postgres: $(OBJS) ../utils/version.o
! # $(CC) -o postgres $(OBJS) ../utils/version.o $(LDFLAGS)
! -rm -f *.o
! find . -name "*.o" -exec cp \{\} . \;
! rm -f SUBSYS.o
! $(CC) -o postgres *.o ../utils/version.o $(LDFLAGS)

$(OBJS): $(DIRS:%=%.dir)

***************
*** 116,122 ****
install: $(LIBDIR) $(BINDIR) $(HEADERDIR) postgres $(POSTGRES_IMP) fmgr.h\
global1.bki.source local1_template1.bki.source \
libpq/pg_hba.conf.sample optimizer/geqo/pg_geqo.sample
!
$(INSTALL) $(INSTL_EXE_OPTS) postgres $(BINDIR)/postgres
ifeq ($(MAKE_EXPORTS), true)
$(INSTALL) $(INSTLOPTS) $(POSTGRES_IMP) $(LIBDIR)/$(POSTGRES_IMP)
- - --- 120,126 ----
install: $(LIBDIR) $(BINDIR) $(HEADERDIR) postgres $(POSTGRES_IMP) fmgr.h\
global1.bki.source local1_template1.bki.source \
libpq/pg_hba.conf.sample optimizer/geqo/pg_geqo.sample
!
$(INSTALL) $(INSTL_EXE_OPTS) postgres $(BINDIR)/postgres
ifeq ($(MAKE_EXPORTS), true)
$(INSTALL) $(INSTLOPTS) $(POSTGRES_IMP) $(LIBDIR)/$(POSTGRES_IMP)

*** ./backend/optimizer/Makefile.orig Wed Feb 19 12:00:34 1997
- - --- ./backend/optimizer/Makefile Tue Jun 3 10:39:47 1997
***************
*** 8,13 ****
- - --- 8,16 ----
#
#-------------------------------------------------------------------------

+ SRCDIR= ../..
+ include ../../Makefile.global
+
all: submake SUBSYS.o

OBJS = path/SUBSYS.o plan/SUBSYS.o prep/SUBSYS.o util/SUBSYS.o geqo/SUBSYS.o

*** ./backend/libpq/pqcomprim.c.orig Mon May 26 00:00:23 1997
- - --- ./backend/libpq/pqcomprim.c Fri Jun 6 16:02:24 1997
***************
*** 32,40 ****
# define hton_l(n) (ntoh_l(n))
# else /* BYTE_ORDER != BIG_ENDIAN */
# if BYTE_ORDER == PDP_ENDIAN
! # #error PDP_ENDIAN macros not written yet
# else /* BYTE_ORDER != anything known */
! # #error BYTE_ORDER not defined as anything understood
# endif /* BYTE_ORDER == PDP_ENDIAN */
# endif /* BYTE_ORDER == BIG_ENDIAN */
#endif /* BYTE_ORDER == LITTLE_ENDIAN */
- - --- 32,40 ----
# define hton_l(n) (ntoh_l(n))
# else /* BYTE_ORDER != BIG_ENDIAN */
# if BYTE_ORDER == PDP_ENDIAN
! # error PDP_ENDIAN macros not written yet
# else /* BYTE_ORDER != anything known */
! # error BYTE_ORDER not defined as anything understood
# endif /* BYTE_ORDER == PDP_ENDIAN */
# endif /* BYTE_ORDER == BIG_ENDIAN */
#endif /* BYTE_ORDER == LITTLE_ENDIAN */

*** ./backend/storage/Makefile.orig Sun Nov 10 00:01:06 1996
- - --- ./backend/storage/Makefile Tue Jun 3 10:41:29 1997
***************
*** 8,13 ****
- - --- 8,16 ----
#
#-------------------------------------------------------------------------

+ SRCDIR= ../..
+ include ../../Makefile.global
+
all: submake SUBSYS.o

OBJS = buffer/SUBSYS.o file/SUBSYS.o ipc/SUBSYS.o large_object/SUBSYS.o \


+------------------------------------+-----------------------------------+
Robert E. Bruccoleri, Ph.D. | Bristol-Myers Squibb |
Principal Scientist | Pharmaceutical Research Institute |
Macromolecular Structure | Room H.3812C, M/S H23-07 |
bruc@acm.org | Route 206 and Province Line Road |
Phone: (609) 252-6165 | P.O. Box 4000 |
Fax: (609) 252-6030 | Princeton, NJ 08543 USA |
+------------------------------------+-----------------------------------+

From scrappy
Date: Tue, 25 Nov 1997 08:09:22 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: Regression test : step misc .. (wait for 60 minuts ...)

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


Your name : Giovanni Sabatini
Your email address : sabatini@dimisem.med.unipg.it

Category : unknown
Severity : critical

Summary: Regression test : step misc .. (wait for 60 minuts ...)

System Configuration
- --------------------
Operating System : AIX 4.2.1

PostgreSQL version : 6.2.1

Compiler used : gcc 2.7.2.3

Hardware:
- ---------
i
IBM AIX/6000 Version 4.2.1
7009-C10

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

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

Problem Description:
- --------------------
when i try to make the regression test at misc .. step
I wait for many minutes but the test dos not go on.

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

Test Case:
- ----------
The regression test.

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

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


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

From scrappy
Date: Tue, 25 Nov 1997 18:21:41 +0200 (EET)
From: Yuri Yurchenko <stf@blackpearl.gu.net>
Subject: install problems

Hi.
After successfully compiling postgresql-6.2.1 and
install procedure i can't do anything more.
As result of any comands as createuser or createdb or psql or other
backend report:
FATAL 1:SetUserId: user "postgres" is not in "pg_user"
And in directory $POSTGRESDIR/data file PG_VERSION
have record 6.1. Is that correct?

From scrappy
Date: Tue, 25 Nov 1997 12:21:21 -0500 (EST)
From: Unprivileged user <nobody>
Subject: Port Bug Report: postmaster does not update pg_database

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


Your name : Felice Carraro
Your email address : felice@dada.it

Category : runtime: back-end
Severity : critical

Summary: postmaster does not update pg_database

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

PostgreSQL version : 6.2.1

Compiler used : gcc 2.7.2.2

Hardware:
- ---------
Pentium, 128 RAM

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


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

Problem Description:
- --------------------
when creating or destroying a database using either creatdb-destroydb or through psql, only the directory data/base/[databasename] is created/removed, but the pg_database remains the same.
No errors are reported from postmaster (even if run with -d 3 option).
Creating/destroying databases using postgres works fine (as initdb does).

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

Test Case:
- ----------
Just compile and install, try running the regression tests...the regression database has only the directory but not an entry in pg_database
Or try using "createdb name". No error is reported from the postmaster

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

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


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

From scrappy
Date: Wed, 26 Nov 1997 01:57:16 +0000 (GMT)
From: "Robert L. Owen" <robert@soulbury.demon.co.uk>
Subject: Compilation errors - Linux

Hi,

I'm having trouble compiling postgres under Slackware 3.1.

I'd be very grateful if you could point me in the right direction.

Many thanks,

Rob.
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Robert L. Owen
Your email address : robert@soulbury.demon.co.uk


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

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

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

Compiler used (example: gcc 2.7.2) : gcc 2.7.2


Please enter a FULL description of your problem:
- ------------------------------------------------
Compilation fails at the end as per items 1.3 and 1.4 of the Linux
specific FAQ *BUT* I have a valid libdl.so installed.
I have upgraded to libdl.so.1.9.5:
- -rwxr-xr-x 1 root root 5412 Aug 9 06:16 /lib/libdl.so.1.9.5
and links are ok:
lrwxrwxrwx 1 root root 10 Nov 21 00:47 /lib/libdl.so -> libdl.so.1
lrwxrwxrwx 1 root root 14 Nov 21 00:47 /lib/libdl.so.1 -> libdl.so.1.9.5
'strings' on libdl.so reveals that it does contain dlopen() and dlclose().
Also, dlfcn.h is in place:
- -rw-r--r-- 1 root root 615 Aug 9 06:16 /usr/include/dlfcn.h
and contains declarations for dlopen and dlclose.
I have run ldconfig and for what it's worth /etc/ld.so.conf contains:
/usr/local/lib
/usr/X11R6/lib
/usr/i486-linuxaout/lib
/usr/openwin/lib
HOWEVER my build fails as follows:
...
make[2]: Leaving directory `/usr/src/pgsql/src/backend/utils'
gcc -o postgres access/SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o parser/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o -lm -lbsd -ltermcap -lcurses -export-dynamic -Wl,-rpath -Wl,/usr/local/pgsql/lib
utils/SUBSYS.o: In function `handle_load':
utils/SUBSYS.o(.text+0x1bc35): undefined reference to `dlopen'
utils/SUBSYS.o(.text+0x1bc47): undefined reference to `dlerror'
utils/SUBSYS.o(.text+0x1bca8): undefined reference to `dlsym'
utils/SUBSYS.o: In function `load_file':
utils/SUBSYS.o(.text+0x1bd41): undefined reference to `dlclose'
utils/SUBSYS.o(.text+0x1bd9f): undefined reference to `dlclose'
make[1]: *** [postgres] Error 1
make[1]: Leaving directory `/usr/src/pgsql/src/backend'
make: *** [all] Error 2

The machine is installed with Slackware 3.1 with the kernel upgraded to
2.0.31. Have other people successfully built on this configuration?
Am I being really dumb?


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

From scrappy
Date: Wed, 26 Nov 1997 11:52:56 +0100
From: Jochen Hoff <jochen@duckhome.snafu.de>
Subject: Problems with ./configure and pgsql 6.2

Hi

I have read all docs and most of Mailinglists. But i coudnt find
something like this.

configure reports :

checking for scoinst... no
checking for install... /usr/local/bin/install
- - Using /usr/local/bin/install
./configure: test: integer expression expected before -eq
configure: error: echo behaviour undetermined

config.log stops at:

configure:1035: checking for install

install is: install (GNU fileutils) 3.16
Linux is: linux-2.0.29
gcc is : gcc version 2.7.2.1
flex is: flex version 2.5.4
bison is: GNU Bison version 1.22

After having this problem I hat updatet most of GNU on Sunday.

All Compiling and configure with gnu-tools work fine. No problesm.

All path are the same as in pgsl Install, user postgres is owner.
group is postgres.

And at last. I dont understand the Errormessage. In Line 1045 of
configrue i found:
if eval "test \"`echo '$''{'ac_cv_path_INSTALL'+set}'`\" = set"; then
echo $ac_n "(cached) $ac_c" 1>&6

And some lines before i saw:
INSTALLPATH="/usr/ucb:$PATH"
for ac_prog in ginstall installbsd bsdinst scoinst install
do
# Extract the first word of "$ac_prog", so it can be a program name with
args.

Whats to the hell is /usr/ucb.

Please help

sincerly
jochen

From scrappy
Date: Wed, 26 Nov 1997 07:47:33 -0500 (EST)
From: The Hermit Hacker <scrappy@hub.org>
Subject: Re: [PORTS] Compilation errors - Linux
On Wed, 26 Nov 1997, Robert L. Owen wrote:

Hi,

I'm having trouble compiling postgres under Slackware 3.1.

I'd be very grateful if you could point me in the right direction.

Many thanks,

Rob.
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name : Robert L. Owen
Your email address : robert@soulbury.demon.co.uk


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

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

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

Compiler used (example: gcc 2.7.2) : gcc 2.7.2


Please enter a FULL description of your problem:
------------------------------------------------
Compilation fails at the end as per items 1.3 and 1..4 of the Linux
specific FAQ *BUT* I have a valid libdl.so installed.
I have upgraded to libdl.so.1.9.5:
-rwxr-xr-x 1 root root 5412 Aug 9 06:16 /lib/libdl.so.1.9.5
and links are ok:
lrwxrwxrwx 1 root root 10 Nov 21 00:47 /lib/libdl.so -> libdl.so.1
lrwxrwxrwx 1 root root 14 Nov 21 00:47 /lib/libdl.so.1 -> libdl.so.1.9.5
'strings' on libdl.so reveals that it does contain dlopen() and dlclose().
Also, dlfcn.h is in place:
-rw-r--r-- 1 root root 615 Aug 9 06:16 /usr/include/dlfcn.h
and contains declarations for dlopen and dlclose.
I have run ldconfig and for what it's worth /etc/ld.so.conf contains:
/usr/local/lib
/usr/X11R6/lib
/usr/i486-linuxaout/lib
/usr/openwin/lib
Ummm...for starters, if this is all your ld.so.conf contains, where
is the /lib directory, where libdl is installed? *raised eyebrow*
HOWEVER my build fails as follows:
...
make[2]: Leaving directory `/usr/src/pgsql/src/backend/utils'
gcc -o postgres access/SUBSYS..o bootstrap/SUBSYS.o catalog/SUBSYS.o \
commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o \
main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o parser/SUBSYS.o \
port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o \
storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../utils/version.o \
-lm -lbsd -ltermcap -lcurses -export-dynamic -Wl,-rpath \
-Wl,/usr/local/pgsql/lib

When you run configure, try adding /lib to the list of where to look
for libraries...you should have a -ldl in here somewhere, so its as if its
not even finding the library...

From scrappy
Date: Wed, 26 Nov 1997 22:22:41 -0500 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] PostgreSQL on Irix 6
Gentlemen:
There is a really nasty loader bug in the compiler system (7.1)
on Irix 6.x, and the error that Lasse Petersen is the result of it.
Here is the original message. I don't know if all the changes have been
folded into the current release.

Here are the patches:

*** ./backend/access/Makefile.orig Sun Nov 10 00:00:15 1996
- --- ./backend/access/Makefile Tue Jun 3 10:22:32 1997
***************
*** 8,13 ****
- --- 8,16 ----

Please resend the patch. As you can see above, the dashes are messed
up, and there are other problems I can't find. Thanks.

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

From scrappy
Date: Thu, 27 Nov 1997 18:10:24 +0100 (MET)
From: Piero Serini <piero@esi.it>
Subject: Re: postgresql-6.2.1 - more on tests

Hello.
Is there any side effect in enabling SYSVSHM?
Nothing that I'm aware of...I automatically enable all three in
my kernel when I build a new system, as alot of things use shared memory
*shrug*
Ok, now it seems to work. At least it doesn't coredump.

I get some failure during the tests. Since I'm new at this dbase
system, I'm sending you a uuencoded gzipped tar file with the
tests results (failed ones only), along with some comment on my
part. Hope this can be useful not only to me (:) but as a test
on FBSD also.

If you have time, I'd like to know if those tests I couldn't un-
derstand are to be considered ok, so that I can learn something.

The failed tests are:

int2 .. failed different error message - the test seems ok
int4 .. failed different error message - the test seems ok
oidint2 .. failed different error message - the test seems ok
oidint4 .. failed different error message - the test seems ok

float8 .. failed I'm not sure about the meaning here
tinterval .. failed I'm not sure about the meaning here

numerology .. failed different # of rows - it also contains empty rows
random .. failed different # of rows

geometry .. failed seems a matter of precision
select_views .. failed seems a matter of precision

misc .. failed missing copy_seq (?)

Many thanks for your support!


begin 644 failed.tar.gz
M'XL(`,^G?30``^Q]:7<;N;'H?'W\%<CDW"O))FELO7E+/+:2ZQR/[2=[;MZ<
M.7-]6E1+8DR1&K+E)8?G_O97V+H!],(F15E*ADC&:J)1A4)M*!30W:?I>)*=
M//CN)@OB.`H"]!U"*`K57X2P_JM_H)"SB%$6!@PA0BCGWZ'@1JG2Y6J1IW.$
MOKN<+?*S>;9H:C>?S?)O0<\W+J=*_N-I3H>SJYL9(<$XY+Q)_@2#L+7\240Q
M7!,:A?0[A&^$&J_\SN7_?W\Z//KY(7I^=/CL_2%Z_^R'5X?HY>OW],/['U[M
MGQ(D%./@44\W>_GZW>'1>]'@C=WJ`/WWLU<_';Y#^WMX;YW6A#*^%L!@;0C&
MAX$`^/NSH]</+\\^I/EL_!!E\_EL#H-#WXO[WS]$HW2ZEZ/+=+[(T/=0LT8'
MH*S1>H-8'P1,"$K3..99>C*>GJ'O53,8SE&VN)KD*)_-T"2=GV7=>TH7)Z=M
M_!+W?7[).M/%N\-7A\_?H[T]].P=.AU_ROI%3\-[CWJB9BGL_I3T!E#N#V3I
MB:JE\@SF6LA:7P^L:\D]=:TXV=L/T'SV>7'0JZ=A=C7OH_'P'OK+T9L?"V+0
M&/W]OPZ/#N$..Z/GCIPAT]^%#H>]`)("T$-F=,+Y-POBW(FPVS5;2]<3F%P`L
M%47W%3%+D.(^$7ULI0N^21?YY]EJ[MJC``"+MQ9K+6X6#*1M#%RO:[[5KL_G
MV6K6/G;$)V%LM7+TRC%+1[-*DMA62>(W3U('`3VMT0U;/DH\A72VI1=/:_3B
MNMUV$L#3>IUP^6^QO^"^Q?SMJ</3>G78.C4K'-&^).8_T![5G#D0;HDXGJ].
M0+KK5O^TB@]^W_P`;4%$RE;:F:*F;=&]^A?=*QD@[G_Q*7;F=?GGBST_681I
MR[7(T_/6$E$>QO;LM1Q8-9*A`FI`[9E,XJ&K(H#FX?".PZD;3W5`_HBJ0T(U
M8PJ#P$S5>E`#5;7FJ.ZO+:2.HZ+>J.!/Z(T*_E!G5(-*T*'^!)N/:LNRVF14
M\D^RA5$-;L*@!MZ0+/*U05EC5-0KXNWQ=`JIFX>S72'Y(ZH."57'A*J#&BBY
MK3FJ!S=E4+Z;0"&)W%&A05FE1T5"%C-W5*IJXU'=L//;UJAN.T?R[US*_!^_
MK?P?QP$N\W^$J/P?V>7_OD5IR/]Q*__'&Q-5?*W\7TUKX16"<"V0P08PV\T!
MUG1`"8]XS$+>DM6K&\N&<"K-ITO'I*`NW7.#-?W>4&Z05W*#2$T^]JSCSSGN
MC(/4I!.$9(YKD+UF<K&=;'XWR*XLQVNHWG;J
ML;6+[:0>ZWA?EWJT..\SWF>SR]3UTDZMY/`;)Z>:^*@CJ"%%:2MG53NKWJ&J
MGQZMZR:KVFGEMTAK!S'7)37KI5P(V9+Q5C6N+M%Y$Z1TDF!#\K-)@+[\;/$Y
MTMNRHC5D1;\=F2N<9\=T:8N8;4K6S)ZVD]*8/:URSF&;DT,MK5+_VE8>E5?6
MWIHR??VE,AD[Q-J>Q*';GJUEAC4AM#)KRT1K>:,4@8(N,J[^C2TF7G\GXV],
MT:X:?SL/VOB@Z*SRHKB.J_PHKWF5)X.6Z,ZZWEZB=\>;YG1Q!]ZTLJ:9,X,&
MQCA#=_DR<'AFC=P:>(4KW1=BG9/.OV>F-.:L;]:*ZKRM+"&):(,5R6PPK>$,
M(CAB$2<Q93569-W<5N;[]\2;`;W/="0GX[&>HIXTA5M\0'5$+Z-TW9PV-:<#
M&$<1H.DPJU?RB#4"@CVKKD0>0F4C>@:,-P:#A;+;H96(.4/S`Z3.+8O(YU>"
M+/A78<\!_2KLO`MVOBEVZH1%%G9^+=I%WL_@@=5]DB06G:?I9`&HY!\MG5/4
M@HW_02E!-LV_?E`"LG[T?$N0A39*[0]_D"JX&']YU(-_M$Z%3<U%;+#Z/T%?
M-@6ZLJE"2!JS-!0`A.CH)HJZ+Z$/"O".AG&R^&V>[^^%0IZGDUF:QP<"/!N?
MG>>/>O*/U7O<A&;YP$:Q$09`02,'Q6H6W/8^Q:[<3-'[?[/QR<T]`M"^_X<8
MS%_6_E\(<Q'C/-CM_WV+4K?_]^;E"_L1`*T;]1M4;EMO:^]!$D>L86>K#3#8
M"!!@'K0]']!*:N..X@JH!R5P^R:<;-9Q]ZVQSW5I%)MO\-^J/3OXKV[;3E2W
M!-96K\7F':B+*EZPK$+50B>*GX'ULY!?V1CXBY'ZB>%*86X/^F6"<F:R@A:-
M:*83@S.]P5,JFMGBL6AW2;=(;4U*JDVWU;V+?3>[>[GSMA;O.C.KPR9A!WJ?
M7)?>=EEWI5<G?3L0[-*K<KTNP3[%/LD^D0Z5J_=A5M/XU&.JV`+IIH.NQ-NW
M/SK:P]-F>W!(<?JN&,.+HS=O]21B=_5H%S[>U>+$?S=T!&Q5_$<Q*>,_2F3\
MQW;/?WZ3TAS_<3?^:S@%YK9=._ZK!^P0_]4`=HO_UCV%M@)*QW]Q@M5%!%<=
M@T$'9JW(L(::=:G_!I$A_Q>(#/FM1H8UO=_IR+".WCL=&=81?-<BPQH:;R\R
MK"/FAB)#OHL,[T#1\9]*!=_0$P#M\1^%NT$9_S'Q_A?&<+2+_[Y%J8O__O+J
MS;/WL0G_]%Y%;7CAM+2?`A@V/0?0!`$ZPH=L7:@!X\.X*=YK[&I81%W"767W
M*5Z;6@_%8`,4../6X?T?TA/-:8B]+J]RF(#G%VF.3+NUN-(5]V`#Y``RX&N/
M=E`%JXD;2^AJV&B5RD:\%V#@*HB.?I26U=U1FE0+4Z,N]7<&Q9UF"FKO[$>K
M0[%3,U&73$*G>IX^+2)'.;Y*&+85WMTNA\*5D<Q*!CVQ^&/.H5;?MZ&:=#I[
MVM:CZ0K")]%YY5!X4>I.A_OA9PU'<.TM)2,3M#8Q?PV$^E;[PJH#.[2*6A+X
M-^;':H,MM>.)5@_WV1N?&RT&VTBZ=T?K=3N36@RV:S^&0ZT&NYI#6F&>^#[M
M=\.BPJC$Z;53?78:IE%Y\XM`6V&=J+3\G7B^`N*PRAK7*LLO-915%L%6J:TL
M5LDULZLXDH8Y\WM`M:P4$P<`5&M)BPE7`08D2;H];6%Q]_XWXNZZS&WC;9)4
MZEI9VSA1-W*V.AFOS=@'_[)J._3U=CVU%5K8RMQJ+5F;NX-_0;4EF-1'X5M2
MVQJM7:6V.H($=OP/VJ-#Q=#%;U?I//MP2FH9BSZ?9_.L(;0L05T&F1`S#DD\
MY,F*G+%<%"EA_UGV`Y7I\:*)HI8ETU*!U<AT39'6AN=KKKC67(8M:^I:5AYK
M+D?67*.LN7#9:+UGB?T_C-CS^=5TM(G@#:!#P&T*OKYYK>"AL@G[%@2_#4FN
MV;R[X$_5PXM0.Y]=34\VD;P!="CXEY%\T(3]WU'RSKR^?&",7IP8;Y+\!O.Z
M1N=1UBS]]:,F1H9A@L.$ABQ)`BW#]JF=J()#\4\"4=.*N=T'$(':.E'30[2/
M'LEK=?S^R^6'R72+3"X0WAB3ZRK7B)]8O#J`<@$2-2=V>=19:W"IPJ-CI7-K
M>2X#5&'A[7BN(<2KC-"813&-K.8-GFM(PQ!'G(I3[!3'J-5S\6$2)2"3((&J
M*`RR^V'8XKGHD!%",:<<0W6<#<+H+LQ9N\2]YLU/;U^(?;22'P+XW>%[)!<)
M%IM,/F>O=#'NW<+7U''].#TIDT(D$[M/Z'0^N_`L3.[^R)T?<>SH<C:>YN#P
M1MEE/IY-_P!^,4.3=)$CK\GL,INGH@G*QM!F+F&RD^P$3;*S=(+FZ?0L6Z#9
M''U.%RA%)^-/XY,,'7]%_\SFLQ4$_\]*@INVJP8#-/N4S>'6Y^8^]A^A?>G<
M#ZKXO16;8"_2?:H33GGZ$3@R.T.STQ5#Z=K-XU7=I&@*/,W!8M#TZN(XFS?W
M^5!W6(3!+!NV
M0ZQS`Z]]@ZSP0J5Z/=`,;[6&&#3VH:>VZN#;]7U<BY-K\7(MSJS%_ZR^-6AQ
MG,W^L2XUA2T1W/:AA5W96M'G?\#W@`V`3_IZ`V>`5IS_#B&4+\__<"Q>"4HC
MO#O_\RU*W?F?]X[^$V/>@AXSF5GY6'0)R7+%P;"W6P
MN.N\;-I'9JU1X@1T;XY>'!ZA'WY&<B<^FZY\N9WW'I?*R^XD;/F*<XVO_%1'
MZ6S].<WY[;7W\-G].:_%PMY<6)6>8+<4GKAH$9UI9_%<G/4O.>Y$LOK%6C(Z
MM3@$"^G7+V3U8XO.Z_3:+N?I6&;K;4$+C+Z<13/KD(?[WFK[]?3.MW+DC%GL
MV@Y88.W@XDVO+?SFPQ"DBPRID6'#T[=..Y>;=+4,GV@-MN3W1-%WG=Z,I:_?
M5UT^P1,R]85L7MCBR-B*?8P$'$'BM2XKH6=55'\]>O/3V\+>@&QJ+MAJ]RF!
M2VX26%T,Y/MJ#N25C/E[R']73=^+;CMBI^:%.`)M9ZP:^,7+=^]?OGXN5[/J
M-+LE'=F1_28,@9XVGD$O4/311?IE_Y3)=!Q<?I!.'VK'4UD+2TRX5+6&8&=D
MBOF@#Z)K2ST,;@NANE0'ZHL[I6]&RZ*-58D:%U&-43ZI3_8T!>JT/AU3'Z%?
MFZ&B=L?0M1BZ;SAZ'Y&"K9>3J\4'8:V&L0-S$\8,_XF[&_"W!"[9JKKRV*I;
MW0!;![7K6L'6NAL[MMXJ6ZTG:XI9\E'+3=YX4[K^QKO:O]_V@F57MEKT^O\L
MFUUD^?PF5O^KUO]!A"-K_1_*YW^B8/?\SS<IS:=S1]DTS^;[>I]4_2HV27]X
M\__4^DP>RE4WW<RGBJ#W21_@=<9QG_:I]6,8]-F!_L'@LN,SJ?M__C.Z0T0M
MQE_Z:M^D@57/7QX]?W6H"(/&AJ[:!SGW<1\?Z%E!TDF=7ZSY'L9]F!T.RE_X
M8.5C$Y+T9G;>7<)5\-!(^-LWKW[^ZYO79OM-KT+_*%L_1?J]]\5HFDOCQ%^=
M\07M0^:4OE^AQTA7M^OP;OU+,K3.++Q]`Q.[7+-=DG+(X\7Y;#[^YVR:IY-]
M"=!'>U)2>P\?2I4]<)XMML=K2U5=PW(:?FV+-MD&_6G@$;1M>N2YSFZ\^I3-
M\_'(YE0P!,WEP\!FE_,Z`%]#%&$%6(?/D*S!JF4=1=LD:#2[FL*J[E*.?C)<
MR'_0'V6%N#\6!K/(1F)GN"#YU;O#OTJ*)WV;_$>]UV_>OWQ^^#"7>Z'C!9K.
M]+[R;`XX3^'?_.MEMD"317:&TNF)\J$&[.?9%?H\GDS,#O1Y^BE#^0S-,P&%
M\G/`^-M5-O^*KA9BXSJ=&LCLR^5D/!KG:)0N8#30SU>#RR`YR4['TTQN?QN2
MU.:@HLNE2'>@<SYOWAX>/7O_YJCAG-%XGG]U."AY]\<_2DX*%D]FBVR1K^:>
M0F4)=KEH\U1+C7BE.W/5H]VY=7%]YFVOY02`EK](%]^'Z9,?_%JAM/#_;92:
MMLK&MXU4X-@VI86-K4)J.N]$:=`?$$'#-BD%EI)./%V'4EOZXKJ_'_;#.J1%
MPPY(;>EO#ZDE_:TAM:7?BE14=Z;4DO[6*+6EOS5*'=O'0+7`"XP>N'JUU'7=
MD#JVOS6DMNUO"ZEC^UNCU+;];2%U;'];2&WI#_3'!F5,#YY%_1AP?/`K-!QB
M3&..*0N#.`GBB/9),&0Q#PF/0TQ#?E`K_5:D@V28)!$)$DYI$%.L<8:`%!..
M>40/:J7?CI0*I'$2$TK#*"")0AJ0,(XYC1AF![72;T4:#'$2\@C'C%+"DU#A
M9&'$>1*%"0T.ZJ7?3BD'2GDB3YKR(&1<4QJP**`Q"4EX4"O]5J3BR"O&22(^
M)0!L4"C%!Y2!G0PGQ7JY8OLPG\@)!?CL32E+?;.;2CFVOS6DMNUO"ZEC^UNC
MU+;];2%U;/^Z2$%A&I==Z4)E%HYG7TQ*!"[K<PKBQG9*U\5ZQV+6ZH021C'C
M+`C`>/M^A7"?E4:5F@.]9(W(,"(XC&)"XC#@43^B;H5`%R9>HT$8>ZTT.E`[
MP,]8@H.$T8CW0Z]"4><U&F"WAD4Z,<'\<?":P9+*8+%70XM<3C3$%MW@:=P*
M0)>`GZ4Q4$'BF#`>](E;$QR@(E$489L+0=_]+7E'DZ&-#>:P2J,.N27Q50N5
M:CQ6#X:;!7`^3Z>+2>JL?W7.$1W["[@"S=("\Q5VQ4JK9YLEE;&Z'^LY343"
MLJ^SFPU-9()S*'@OKN"_@P8L3"?M:K$,8DE,X:;KFD02S2!QJ/&:%,3(2T5-
M+9;(H<9M0B!2[9?>O:8)[DO+HOW`'I*+!:RB'RE:Q&58I45A$?\V\B42LT$H
ML103@](?$3/QG9E-JH.F_4$B6H`9
MDT),7A-@QB!6C)'7B4@DU6*1?VOY0B`J$PI3S$$U35B?2.T%]25-6*!_HA1&
M75.?E@*+_%M@V:?M+X_T;7YP0S;?R>H[V7TGR^]D^YVLORI/+<X6;T0T4:W^
MB)1$D4:/9#"U^B10397,\!8N3J,0%!T:@;ZW81)JCK45"^.IHTECDG\:,0U@
M3H6NJ#*?0/[@5?N1]40UXO('JVD4BD;*#,4EK=+D8BI_N-ZE3\1,+JRGF7`1
M\\O1D18^"9]-`MF9O.1U?-*8Y)]F/L7@8_2$,FCR$#`)#"(UI5A^IFY.&83E
MI#*H<XT&D_QK85K73]PK_,1\EJ_M)`P,JI9.;L)S%"J=4Y<,NBO-!A3$2UM<
MQL!*2L`5:]($*HQ=*3E<L:"AF<:Q`AO6L0QO=[$F%*$5+^L-P80RLJUQ)=4A
MD`)=BXE!M`$QK70>\3!N#K8@\H65/X$VHFT<#VF?)</PP!\"$W:*P<<H8XO[
M25+C1B2\BTW]<KTRU[('G];"$!@@\$3XB/X@<#CG-DL$J[ABG.3A@->8KL`6
M".KU12/?>(->>LU"U8RVBEXW$]H9M&AO@2VL8.OD6+13>;"N4RFW"O<EY./!
M4W^?5QS`)L;YM#F>S4IU:VE+Q4DSR="<"GM:N=NQFF*#6*Q?Y2)6H6?BVH]]
M-D5,I?%3O:A0OUBP(7(;L:9RRQ3C(8Z-28//6IG_7P,Q46(3_@1ZD5F#>.7N
M4A?$-!2XY,),R3&^CFY4*(ZYPDRW1S$.`T*B,`BBD+,$E*+@..8QXSRA(>4B
MB1%UZ<U&G$0AX!0/WX1!'$<2)>7BF;J0$?@GQ)K_C`;0@$;P'TE".38<T8!$
M+$Y8Q)*8!@[AF+`DPB'\%_`$2\G@
M$'-&2"`R,&%`R<%*BGU"^ET;VKX":-$[#6$<BDR7-D$,\Q@#@I*`AB%;O6_F
M\EBX"8R#A(C]ABADC/2%;G`:8A8$F"9!'&JCQ"2*`L(CD<Q*N""($VYUSPZ0
M[RN*UH)V@;A`&D1)'&O$E/(8!!%)0JA`#,,/Q1:"[L%'7"6E(\5^,T_=:&/D
MMTFQ$#.%&,QY&ZA=Q$.L%$J:W3812ZQ=%6H%XGU:3:Z_1V?9;S/T_@W:FYV>
M-KP60GX"5I]&7)C<^U3][.N#]Y=I?JY/&SU[_U\J$R_AEKKA4K:H)<R9Y%>E
M+_0SC;3YF('7;M]J5Q-DZ7:\V+A67.=]&3"*3>R-\'5OUW4<<GM%I;N86&O_
MVM!NWVMGI:OBU(E.
M"@E66S=DJPHOY`TBD1!S>\4Q6J.Z1+^+5:<*30`KFIR,%_F'].2DB(:-`@.4
MT6'3!C65EC<QU>EPHRP]F3;*TFOWBQZ7:B?_<I4@$?"E#G?%MT:_G<;QBUA7
MR:U!ROJT;;QNNVJ_[3KLB/L>B)N*/%I%VA=7DY72AC9^YY*`U8(NQLR58L/J
MSA]P,5RK2>U*T3I.,]"YRE"EO8@EU)58.G6TDMQ?]L4Y`-&(8Z%=OU:;['M-
MG'5Y179'AV8&:GCRWDJ,J=./E[/)5_L"_6^QJAV)`\GCZ:*4;.F\9//FC)EU
M'K+FW2O+`G,IXQ6G'9VO%QDTUIF&&I^X-*<L*YDKM;M>!W):"U*<1^@,4IXV
MZ-Y+<9:@,TAY4J`SB,VQRF310)C%L:X@%L<Z@M@<Z]J+Q;&.(#;'.H+8'*O,
MHJMUK`JRDF,=06R.=>W%XEA'$)MC'4%<CGGAQ6H=ZPKB<*P3B,NQ;KTX'.L$
MXG*L$62-+0S?4PO__.?"89>>.CNY,5<-J-?WU9LXZTV\]2;N>A-_O8G#WL1C
M;^*R-_'9FSCM3;SV)FY[$[^]B>/>Q'-OXKHW\=V;..]-O/<F[GL3_[V)`]_$
M@V_BPC?QX2N=N';?K6D><,YGULY1-4%0I'M42V05)U'0G#!0C5ESXJ!LT)!`
M4`U([&NV!F2OMYCIOI?W+!.EZDH
M(EG$"G:Q<LC5YK38:W8/][C'?*P\CHW7_%NS>-^0M<4:W3Q4*9]+.Q%MFMC=
MP-:2'TYJ;L-J-T?2:7C*C&:7V?2#2*65XT67<E#[\N6O=9:F>5#NRHX7`HW%
MA`*KS_AF;5RA?2N2L<VYRQ79S^9D:Z':_IV#:_?8D*IJ2YAV>42_JJ[^:?3.
MOF!7MEVV?'Q_5]8LPB;`P`9,']0:!DF,HY`2P@+XVR?#`!>%<W5B:LB3HA`2
M]AVH6#8".$8P94$B]A?E]QK4Y&8C)%$8.\!BRUC-7T65>*=^W^XQBA+I1`9L
MB$.*>41BS`(N7HI?`89Z=8ZSZ)+AA$LJ2H0A5\]NE&`1_.]`GLD,$H8C#`.`
MT=!(#D*F>1V<P!87GD:QS\P8_M]W.!=`S<&!X7^2J--H<3`,,0TX9E$,O(S[
M`1V6_.*:KGA8L@,'O!_')51(U``+J(!@D?/%`G]@U\<)<R"AG<Q=1V55'":T
M#T!%=S1D$CT&CUS4QN);!M0%C6(>B[-<<=$AH)>)YP"7@#$EP/N8%V`)H5PT
MLMKP$/"'_4$BF<J3H<T.ZD!'("_FL3&!_ZM#905&4:-G$<-_E5L'G6(,@Z0Q
MB1,2)3"[V?HOGIGQ]#\.:-2/+"C0%Y?]0$9`^X)V9N&B"0\=.!"3:!-859Q!
MF\#65"8/U`F#*PV0`W=[V$).Q<$4
M=<#:4?D([-(!CJ,DC'P."L$!'248J!B-W3T'S7_:-WVX_H?5^!_L^1_2YW4.
MJ(0C8+U]'1B[SH=7G0_SG0^K.!]NZ3Y()6&Q!R?]CDVF^#J.7`-4_`YV_0Y-
M/`F`#H>).G,^P([3(4GD@E.@+O&Y*!V/`QB+AT,/7/XGYH'01,@TB7B0`'3(
M(6+#@(/`5J,`\*A=3P=;D'B@"M*NB2-HPFV-%"Z*
MB`5UDI35L70.#F@4B\?*N-U&6J:-#?P/M+&&C.5Y&P<S!_:31/+&AA1V[X!2
M3CS^@<C!2]K<(J`$U2.S14A-P'@LWH/GQ17G;U=))Q*'%=]O\QY83Z1DB0T)
MOM\!U*Z?V'7@^_L\J;A^*IX7!NN"X<64)8S#1`;3.TX\>#$!]`=6I\;_$PNI
MF`#`@X<5_V^)0$I@H`9A@P8TC!U8X_TM-HH(03C_I-;Y"_YW>%6664+$8G6X
M6T7\SF+V2H1L/?;*Q2D(JR(,(W>>-XS`B
M*V)6NWD2B<=D[1I*HJ`:C]I/)?.(,^?198A0O:G6CC6MIYX3DH0.I)ANF\-(
M"Q*,6ASUM1Z%3H(@="=)+T*T2(;P((H=Z(A!E3_[F>C/?F::PESL/%C-(6!H
MBNSL)[)AZG7@<!`V!FT6',QT(7,?TA8N-&P)R&QR$^'1;6CPWN+P9FNLY6DR
MK]/DFBB*^5K,*UK<$"'Y"HQ=!<912_!#*MJ+/>VE=:,M(QO["7.A5.YSZ7%E
MYK2C%JLE+(A<2&F<C1&)U1)TV7W0'<L#U$W1AMT0RT#%JJ$AJ1NMBB/LY^$#
M&D3.,_/&:.N#!*NE,EI<,=K6`,!J'T7>D_C&<AOF=HMJ,5[JP'IVVV'6'HWG
MHXE(U_:1"$*L9+79N=:OMY3M6B<WR=S'BKD!?EHR_+'>J=*UIDYD.$U#75?L
M-(EZTT[M)*F6NDX?$]3XVH>IW]=JQMFTT^$-T!YH^QL(!#EB6P+6NT1\UE">
M_6?DJ;DI_4CC3?E&5;'R>.IJJ;@I]R#P4X^@]FRN?,5DS6!;W_KY!#']VL]Z
M)JPHUXATC#Q7OO43Y@7,22@R`#AD\#^C'JM?&"J8#T;&&9:1<QP\7?F:SO(4
MR(B8TQZ2->90IMS9&(L70JH78LJGRF3;`W,\,YV.LIHH&%KU&UYE647U5'UK
MHWA9N\';+\FQWL+X^+%SQL05YE*UE)>FKB"S%(@GQ[9#)_;>[6/]<EKA()\Z
M6\8P444AS(FP,!)Y@<B#$L;!E(K;F]-"9,)<8&X3$USL0LF>:J`\O:1M%)90
M$$A&40AS*!?I@J`=JMC6#H9AS$2`0FD<$.I#"=,-"@J+C?IPR"'8A3@BP!!U
ML;@-JMP.;X?RN%'TY7&CG?,%5#P4`36#-6?$87H.VJ!*"E$BS!/"OR"*(PB_
M6BDL>.@22'`KYQO&Y4.Y?5D4$@B-+!?<*J^"0@$$89]X@QB!Q7,K-RPH.J2,
M!%RDEB(:M4JYM!0:#L%2(EC21!&C/@_=ODHH!`%!!`$FL)Y!W$/;N%%",3(4
M\B4)A*(1#_QQF3>?$?S4A@+-&$*XC5D<@/+'O`VJY#S4#<7C<*%PX#0.VZ!*
MJP36P9P)\7I,`Q[S5@K+PS,@WV$(L1"X&G`<4=+:5Z%1$$P-H1<JI(QIZ%N*
M"U5(F8+``O`<,8TARHLB^US*;;^X?E>V4O3W'W+Y<N=/Z>0F/@#1_OT'*MQJ
M\?T'1KCX_B,LZ';??_@6I?:39A"Z'1[]][-7,GX37S5#A7XT?,?,AY!A.?S^
MZ?`=VM_[Y?O!>'HZGH[SK]^C[XO+7_<VQ/9C^A5FQ3XB"8\090^#Y"&A@/EO
MZ11T1]1'#&'VD/"'E&S>S;OL$DEL,;-[>3/*J]4;=Y)=SD;G@/7'V12)<2&"
M,'[(Q/^ABR38'/-?LF,$E@5(`!-]2(*'F$%'HZOY'"+HS?$>IR>@#Q<96EQF
MH_'I>"3?);$`U`IG\1'O]'@AVV5?0'>FXL/AV258&'2NWCZQUX!I;R.R*IK5
MG8Z]^F6U_`*ATV_[EY^[ES7/$C:O+-&RR;:Z4J*1O$MSI,RJT&EE7F_?O0>\
M[ZZF2%E785?*RL3M7PLDT$H8#>8V$C"3MR\$DO=7&1+&4WN[0.(;!/8,0K5>
M,9SWYU?(Z+]6?64(:CB%#=0CV0]6?E,B']XKEKZN:N;E<C>7;_]_@O;^#%9]
M,9OFYXL]_XL-&Y5M[+STMB&SU@]*Y.?S;#U6/7[J\4JBV(JU;<?<MF,JVU'S
M+>@Y:]/S?V;SV7K2LX0'LA/PR_*[K+W]YE<&;V!5CY^XO>VLJI%5VJB^9NE\
M9U*W:E(;R$ZJ.9/"VSG$NR$]TBP^*]>=RU3W?_YGD6J!&/79U9FD#'@`G$BD
MS0L.@:<@H5?]Z][#A\6RZVX*_OJ1YW:BQNNK3XW@.[UQ1ZT1<O7%L)S:'_/R
M-:/OU]"JKB@4XN-398).W7M28B\_;&MUNYUUR9U8U]R)==&=6%=M:UUV+=O8
MUI+L6F:^K<7EM::'&UY7BBW-/,NFVI\4G]P#]V^LW*ZC6_(T:#K+6YR,14+1
MLSI0(&A=%K(A+9#R!9FYNT0<CVSVR9'
MKA_J;F%$VPF]T%;FAJV)YKJ$;(TCUYVR[XQH[HRR;LVA75<T6R/DVJ+9EF>]
M;E2U/=%<DY#K6<T^:7^DOURF=5BYEP'1X\<K5N^X=O6>8'?U7EVUW<%MI+NS
M`_1M[=9F=LO%!G6+\^R9ZMI/ANV9J
MW=[Y%
M<7WD:'8US??OZ9=*SZ;9QT<]6=?3_D!\-;9I>ZH*C#Z?9_,,S<8G0K_V1=40
M?O0!S8&'&*JB&T),@A+Q;;/[SA5M_Q?CQ>B&K'_E^3\6,E+:?R3M'P!V]O\M
MBK:TG]Z^$.?_A"&)B59,B5?3\6]7F4@*2O,R/^^+[PBM#36H0N79Q:6!6N3S
M\?3L2H#-LT_9?)%]&)%0V;6Y=U!&94X]P.S][8=G4/;DQLG_097[HJOB]Z/>
MZS?O7SX_?/AZ-AV<7DU'X@Q8.D%7ER=I#J'A;#KY"@N&^2+756B\0)?9_'0V
MO\A.K@>\$0=H$PNHRX/G%1[0N\R$%T=OWNH#IX*T0CV>OWG[LW+R8NOMP=5B
M_F`R&Z63!XOYZ(&QTM\F@W!(AT16YMDB?S#/1/WBP7AZ>94_&`ZA8G$UR1</
MI#(`%6FYA?<"YA7@OS7)5?J6]VZF=SVK&=,H)S4E65/_&-%'/?VCYP3DR#P0
M0JJ/>?E#H]6QT=L8'-W*Z.08?GCY^MG1SV`Q5R<?0'&VI"8&78NJF":/6LG9
M%G,;"-(,ON>3-$UA\;E,S[*EZ%5]W6VY2"?I_.OR(IW"C?GR[#)=@AV.,A,>
MW1_4/0!GO_G37/?^D9V>HB7,UN*3GM$P,@\JA1@O%^?I'/I;LF%@GEWJC<87
MH@'#XD&98=#G`")N<FBOVT![7K2?C*<GZ1*6:N*#.DD_')(#B9]8[>DP*=HW
M+?,U8](/8EZ_!\'@)%TLEB@M!MQ+)2Y0+WU!S07J':L+9BZXN4#EQ4A=!.8B
M-!>HO)#/)"XA\-07H;F(]$79)O9KX.)$743F(C87B;X@V-28QH28"VHNF-^F
M>D'XZC9P(:CA.6YG&,E
M?_2EG#*_#(_%/'E\=7$\R41Z+ON2H]D<ZE-P1\RH2KH\5AJF%49;@%&`I8)O
M7*L(''U0-T/(J(Z0$?I?M'<^UD34*:FO9<U*4:,+M$V83;II*^!*@5?E7"\H
MVO`8LF;3<1^-"DZ=U'%*B`9<@&&1$@U:CI`IC1^ETB,^FTMY+<_':`'S39X:
M5H#K-#<^SC[.4,$C!6`_A5DP3W4N(.;C13Z>ZANG'2#23^.:&XT0UHVF+^EH
M'HX4]S+#/4O)($Q[_=.K5X9Y(PNISZV!%CY0.@)G+CZI4]8<S[1)%#47X]%Y
M-@$S*&JRR7@A_*@6OL`S2<>P2+=J+L8?97NK)H79:&+7?,S&\KVX;AL7*IU`
M9S#AE#5R=G)[3^<3Q3[2H(-ZICBM8=S+=S;?4+H<@4"R\@7=JTK!WOO^%+NB
M%/X4'`T:1/*5MZ0?!/*E=93VPU"\C46\!``6RN+]*ER\]%&\/])X6PF8+-OI
MLTDUWGDIE4[U*%Y3I-XL('J%?KDHWMMZC94#X(`0`VA`2V`#;A`4OE[WN"ZI
MND>Z&:`U1HM6B]B"6EYPM0#LWF/%:)^]>G]XI-<[2N70T>'K9S\>0A3YZJ<?
M7Z-3$<B>GCZJ`S#&[4)D`B++:B%.:B%.!,3)22W$J!9B)"!&HUJ(XUJ(8P%Q
M?%P+D=9"I`(B3?T0UTREY5R:5F>(-/6,-:U&>J@YBJO$;+4776*D[G'4]2^J
MGP>H,MGGL63RZ:SR`2_-9;CCL=F=A^&^>(L*-6P6[8LYI&`TK81%*PD3B&O%
M+V.YT_GLPHC=$;J,"G"+T*WPOAK55V/XE1$[B1LCL&I8WA*-$[XZNBK"Z98H
MFHJG\?W7`M4XF6<O7I0>9CS-N9^'T^U$$NH4XF."6SV0A2YST;FS:N:NOU*8
M0LOP8PE>:YE9DZ2[!+T_*,1AQR,PKY%E$;^&=F"BG',A,MM/`Q1=EK9L!R]P
MBY50L0ME(70#'/^6VQ<L:`OYVD$0W`J*6Q3;T1#<"LM;Q`Z+=%]E4.#T%2VM
MF(M/9E
M0KEVA+3I5@N4NK5/_5Q"W9QE:7Z*U+*M8;Z"_VJ3$&`$J:7TA:<"$HRO*B\%
M8<9QE9>\O$3NI7%IY6587B+WLK`NRYILZ[&4V[*.:JV\-%ZQO(S+RZ2XE&IR
MXH-)-3"NLKQD=6WK+PGOWM92!&+I>JG`U-)*5Y]*:[*MQ[*6:MOZ2QIU;ZNT
MLRG9<3D4.3_QW;;SV?'Q.%O(WTKS+K.YL,XB+RC_5:5FZ2<]T5+D*,_3T<?Q
M]*SWCYGP6<?IXF.6'X.MH]X"_OWJU#1EX%;3=>]F"5.I2ANJZ8UR+UZ^>__R
M-5QH2C_,->WE[^RWJ_'E13;-K5$4=_4HM#>QKJV3Z97U7\^B%=S;V7D^NUPH
M&(OF97KR:5Q\V=:Y<YEE^=X"C6:GIUG66WS\^CF=B!MH>7:5+TH*FD;]30>[
MR9`V@6EF:O.=%M9%Z^BV_;N.A2W66,='/QYJ,PB//Q7S\)7%-Q:/(^O9=+=Q
MUUO['1MXQ6=X^)MLJ8D!_77<<\&.JCLL..'X14/;LNH@S;"654]9W%K'EV\^
MO'MW:'P%PNYS0]O0?2-HDVQ%V]6U[3+K-+_GZ)^CF9(I/4>_'<V6G.DY^NW[1SC+:L?]<IK5^4+
M/5=K[\++Z'/!'_)CE;M.S\[$)G%Y?SYW?A][\,>S+P96_;Z<CVTO>YR+4R4?
MSK/TTOP^C8N?\O>8N[_S+WG9?N3U!^OHT4=:=*E^?UADO]GW2XIZZH6M5OMQ
M_A4A"]_L\JLU@-Z)UY\X3&(QJ'>2G:97D]ST6/PV_-._LR^7<U$'OR]SN[_,
MPR_V[YW[Q@(^R$:]4Z_]:;K(Q?8[QQC+WY-9FO-R?/)W7/X^3Q?GE@34[U("
MZG[H&4]S:O-;)'2<
MWY>S>9Y.C,[U)HOLS+XOCZU8_:N3'N5O\8U#N[WVCN5]\<9>2S_TIS,*^<U3
M1R"]>99./I1*`[\GCKW,9^F)W7[A\6,QF7VVY;7(Y^!,K/;F$(?U.YN6]I9G
MTX_6P7SYVQZO(&9QF9H!](HG0%1%+Y]]M56L]R4=Y99!]_;#X@GA;W3^3Y__
M7&23;)1_^#3./B^V?@ZT[?RG^,`-CLS['RG&C(GW/X8!W9W__!;%3][*A+LR
M"V\FKRW+_#RK^Y#IKMS!LAP9@?J!2$WY_7S8Y]^@E,+J/1N-LL4"'9T@&C2H
MP2_[`T*)^(8(Z[-H&,LO83I5R4'7A[MVY6;+\DWZ<2+>TH%ZS\ZN4O27^3A%
MS\$]?ZQK7$@VX%*,E%J2)5+8\4ZV=Z/8DIV>0&3;U/#Y>%Y(-F+BNSA*D"$G
M1KJB.@ZER'%(HIV$;[78DH4%^&B6-S1\E4ZSPF9Y)`V4XT*J"0^D3%E"=Q*]
M$\66['PRGI[E#=]Y?#$OO7$<8ZHD&QO)0E6D),MWDKT3I;-DCV;I2>&-DR!2
M$50A6:@R?G@GV3M1',G.9U]GX'87Z.UL,<[31:5Q(=E(!<))9$E6"AOC8"?9
M.U&JDGV7C69-C8UDL9)L)$]2RZH0I"RKZ"XVOAO%DNSS=))^RN9@JJM6/3'%
M4K*8!<4\2]4\FS"RD^R=*+9D9_/YN''9\_?T:[F>#;".C<OU;(`#%4'%.\G>
MB>)(]K,X4]-0R@B*BB_/4F6@90XJBF15%.]6/7>C6))],1\O1K/)I+ZA'1LG
M/-:K'E:N9V,>$&6U2;*+HFZ_6)(]G,XJT7!9;&\<A9%>]101%%2I<'DWS=Z1
M8DGV+^EX+C9VZQL^^Y25\VR22).EQ7(VB4,I6!;L)'M'BB79EP,4Q+BUL9$L
MHVJ>C9-R1X"K<!F'91512URR2TO=0ME`LA!!J>T`3+1@94R5J'50&2U'L5H'
MQ>5D',2JI@R\`I6!!IO?27^[I;-DC]*+RV(]&U"B1%OL",0\2E1:*K&JPDJ5
MRD%B"RX(#*J=:+=9-I-LI%TO*8POCK2#ML08$6ZJ=D+[YF4CR2:8Z[QQ&4)A
MIJVQ]+V8AHRJRHA;M=I(=RF-&RV;29:%L9D=^T45U^=EXMB:;%G@[QU`%>8J
MV+*RDPGCH1^!,1:%14MB55=1EA'=3EMTJ4CVP<M!6"=?*=E]$_7J)'%<VBQ)
MM'F&[DM/=N66BBO96IE:C8UDF8R6B&5Q*@XFW*I2J0M";;ND7,D?C)%91ABK
M0S8XPHEML;(NC*TJHHP3AX19+6FDIX(@M.8'1G7C@&"KEL1<.0(>1E8UA'`J
M=J"E*Z!A3,5(K8K`GX7TTBZQ%GMJNR3A)870I\G&?C.U7T^RQAL3M2,06;(E
MA(92WA$'?EC5JC(L)UI"Y3"CJ&0&S,-JV]["EZBJP.)KZ2EV/G=EV5"RI0Z6
MPE')169)4)J,M9S%@=HUP+M=@YLOG27KK'IB%<2PTNR*JH1:53(':?T.O+V_
M.%:RYG0GZVV7C22K@B7.[-DF5A*RCI:SV#L%EU`EQ]WYQF]1-I2LD9IUDIQQ
M);7`JM*[>CLYWD)Q)1MWC(U#%2SAJ!1CJ#9[<%0N/$.=2@RM5CKC;,6;01@[
M\2=72V7&=JNG:Y7U)/M+A?N%/'1FWUKCP*I"55FM5"*9E`Z:*P<-X9:U7)*!
M5[!SV=<JEF3_-CN?+AI.&[LGR1-8MZI52FF@1-;$T>ZACSM2;,E>3<>7V;RA
MX;O<.I4:4_TL7GG>.%:BW<VI=Z58DFTY0HZ\9P1"SF/ED!-2;NY$0:#G7XIW
MRYC;+K9DQY^R^<5L7O_@NWU:)@I5,A'D6YZ#2M0*=W>X[8Z4S20;T8CHC78<
M%S$35*O(%^]VT6^_6)+]<;Q8C!LCJ!\FGTZL[*+*X5>RO'8N.%'^>F?%MU,L
MR;Y./Z7_:'JD!SVW(BB(@!,O-HZCW=L,[E:Q)/MV?#$9-SZMY3P_&Y+0V\V*
M30X"[S9B[D:Q)'LT6V0G_[^]MVV2',G1`^]S_XK\IFZI9\[?7R2[#]J^N9O5
MSLI:,Z.3R<;N0VQ53G=>9V>V955MJ]?\QQ^#`.D@P:@*9C(B&`P\MCLS!4,P
M(ODXX'!W.+![/%`YB-IL-I`%0W-2NU60T+H2$&;_LOOAX6EW()%\Z(V3LJ.;
MT8TH=`Y:R%T#*+._W/UY]_`XJI\W4.Z8S=8'S$M4-0TBY=@ES`BY%\>KF,T>
MLD:(S38B(Q'4FD"9_;AOK?O'7W^[2^Z`\F>9]>V932/,-<$\XZY4)K?VL*`%
MT<'\1BW#8D%09C\]/3_>_?GA_0]30=1?7Q[)60_L4SA/L]?@9K2$QBL!8?:O
MNP\?=O_?[N7+-=R:Q6L(F&Q&@JB8,#%5]B96`,KLC_<O]Q^.J68034(?6^_/
MPL9BD@2*M8`RN]]=W+V;,M:[49T*HVP;&Y.$43SZ$7-="PBS_\_N\?'^W</'
MZ9OO]!0O!;@:G77-78S=$E?6L^L`8?9_[%Y^OOO++R\/3S],<#LX$;`6(EP2
M/T%X*WM0JP%E]O[QW8\'HZ?AR7O&0+C.LQ'2EYRV0NXJ0)G]\>'CXW,SSQXB
MMT90+N#)CC;UW"Y:J]O[&4+M&D"8U1\.5<#=8Y`'Y;W"4-C4LN316P_EJW-[
M*U+XO2@&=1??WQ\Z=Q]5^LJQ)5;'V!6JT-V_A[X7--/:K--LPZ,-GN
MNO)>LO^WD6L=ZP%A]A]>]AN+;>NEB>W%>O)N]C=2X:I'=RMR+X+B,D:V*E8"
MRNRGCQ_O7_[^</\X==8S8#993*`P/;,)[O7D)`YY':`5->\?'PXVB!AZXZ"A
MQ&+/*Z;/B,6N!Y39Q]W+_<_/3],1\O>/U!L[TVTF?CL421[46D"9??GMP\?=
MX\/39";4X%Z/\6FX!]4(\'J`\D;\\1I`J^#>OWO^>#`K=;#JT3X/2OSL16$\
M\^HNH49VI2X!6@5WOYP]N/_4*G?,&J.P\HL*L7ID`T7[LM0E7P$(LW^\__#+
M_<O#;GJWHIX(M#L5;0!E:PB%.3!DA8N798V8[&7PJBJXT8#!UII[T1CPS]D2
MD87B0@WMM8%>-%J!N/GO6B4HXOT130[S-=SWTS4[,FHH'E?O43<2+#M5OQAO
M]^I:V2FJW`XS3:Z8J1@M_`X?B!3*N>K:U:01P>.H%I24(D4'H[*X+6>(*#*1
M05']P[NWD?K$L(`=<G0F(KB,KFN!EX"IHD;U/R($$.GDO_E_I=+7[VZBTI?4
MJ=@.7E&GHMV8P,4KV:M0&`G7F=9G3(.K\7*S6H(1'HD(AG@@'^S25%,5V6`Q
M$]9%NJ<9(4Q/WM4X'12=J[O:\+5)1R*"'!!MB0A*DVVCU/+KF$TP0UE-=A<U
M[AL'(FHEJ1(1P>L:EX@()%70>.KV#1OKR,-BXVA;+HSQ9%S$X"%SIPG7#=7&
MB=]H3S:W(\RB1MW`5MG1S-9Z4/O:\D"C5=7.H(./1,*KP2N9=6BSU95A;P&K
MJX4H;%PZ$'GV01@3ED0Y&9)QC)0K?@.68Q:B_IZ@5@0.,3G"/WC4%(7&$^-U
MS$+4,@B-(E:HK2R2,$LH.S]>QVRW>-%UG@U6?R80%FK/CM<Q"Y39:I])H7N>
MBHR%UDM@*69#X,SVRR"A]@(@S/[3P^/[W8%J4./<Q8#>N!*9V[E72%P-!O6@
M'M^_W!^Z[_X=S9;I5BJ)KE12=VU`V%T#!LR^['[>':JH66NXF?TI#=97K"O5
M?36WKC7>+6SQK!Y2PVVKH,P^/[_<'^PM3&U6*3BT&^PN9DDF7Q4(L\W_>CE0
MI.)N='_68M93/8),)MGVJ$1X70EH=;[=A_OGN^]W[R?CX^]_^O4W4I,<VPB3
MSDG6&V%V1:#,WK\\_/KP]--T?;[!JL=Y/?;&SG5'9'E_,BK\7AJT[N)GRWP-
MYEGCL--H/1'`KB[T,-X8*VFI%\.`V:</OSP?ND,[N->3X["-L.Q4K`^#BII/
M'W=W_[Q[F;S=,[#9V&:OD30([#PKQ*X'KZB[N*>R<[UUGD51EB(D*\&P[N+3
MQX,[%:,]*(N-A$..9!O*8V9G4-)'Z=(8U'#;O?OI_F7WVZ3BT!MC@@O)'8-V
M/48\\EH@-=RV"JGTM54,*GU]^'C_\G3W_>[=P]\?WM5PZB^_?((3H-X;6]@D
M5B35&T7[A'`A=PV02E];!:T:]*_W3Y_N[[1U'P^4#^IC8^QX2.Y!Z^3Q[JP$
MQ>O`!+-.?9'9[BY6W4K4(6/NH@3'ZP"M&O1915I;1D>'U>;[G8I&U)JQ<[))
MO`Y09G=/[UZ>_WY@XWBP4^$CE/K:WX?MN04[=I(JLPZ\CMD`!NH-\<:02>[K
M[0\=H&R%D[.>2X`R^_#R[G#EQ8$W#G#1V]4,MT8$5JPE-%X'7LDL'.YXE2NS
M`0U48N-U8%!1\WGW_HC.PNUA+#CC>H<G0Z4()[M0:X%4U-PJ:'6^SRH.5SUP
M^Z.6ANC705:.!%8"RNSNY_N7X\YG,2O5DSTH"Y6.7))]XW6`,OOC[I>?#U1P
M&WEC9W")0\JW8&PL![0KP9#9E\>#EP0&]8T-E#6C95N,-\"L;%2L`U+?>*N@
MS#X_/GRX__3SM&+-J3"_-U@KT-76']@-Q$N_Z+6`UC?^K.(@-DY:C[RQ3E`/
M2!:T:X%4KMXJ:.7JSRH.;=8:9K,F=+%Q%8%$B+T$QC7)#V*PGL6[>)19[9!'
M6<^N`U)M?JL85)O_X?[I7^Y??KB?JE7QA__5W9_=1\)02=[7+:CLH@10J\*`
MV9>7ATE6]QC,L[F[&5TWCO&P1^QU+7A%'X']I`I7`A3)J=#8,Z":L4I:X0"(
MP1$QRJH$*IQG$GRI+JXFG\-RUHE\`]8O)RTU%<1VV9-G06R7??VQ6-@SVYHO
MG1,V."<]+K!&/)6T@JO8C7D=LQYL-I+<10\EPP/APD-)S>!KG.4B:)$/.C@W
M\HF(X-Z0#_5@WV7LRN!=BHZ((90CITX>AIBW)$-+A7&B@(,C9D?&B8.R*J[6
MQ6Y^"(C(E@SNCUOZ[+@ZGH;J'[^W
M1">FKE[>Y\;7T<S2ZGR-W;&L5!52MWJMHM"E($\8WOI'_77C=<Q.#MPX'K@.
MG/'TP!5B3XS7]1&PZ%2KQU,6MJ6"SD240%1WJJS#UK5!.44T=8K@,&,.GH@U
M>MMHZ5?AAI</EBZY,*SSM;7+7IJ@M4CCL+.I7VABLJ!M,ZFU;7R.&?>_Z4,@
MA>2ZUNK2^T-Z?]P-*I!`U&-(;(F;BZ1Z*F0@.T]ZK)DN)*%Z2H-9-3[>D<0J
M?"(Y`^[#BPV\^)/C5<SJB`W%:L,6'1WV!4M$9$!$;_^`J#9@T2%&%&I/`NL0
ML868WN=652FT&JMK$QWPMQ"!QD91.5$]AZW<2,R<L554U6H\")3<WG=;K=_K
M?89[2\H&7P-E#X-7:1I.0R197P-&(-G2<`,<G*$Q,*RZB!),4*^=`J2/P%8A
M?02V"EJ3?/?PX>#FXC##+70M)!O?8PB[3<`+>PQ:[KY?&H39/^WNOG_<_395
MYNMNR*S&3CS>U9E(R>VL=8$R^_SNTX=#Q?E&]WI4&&_^^HR[2^)ZUP%:N7KW
MP]/SXV1IOKM15FJ&$)74F@]P[IYD1;(6#)C]^/'Y8$WRP3R+[>W('8%&E#+N
MU(0D+OGR&##[Z5_N7PZYXV&VC,:ZB_7P!+<JI-;76D"9???=XZ>#_7H&S#I<
MH=>*FHU(3MY7!<+L?]U]?'A^VCU.*PYM%G:-:F1L8./&24/*U8!6FW]^^?CA
MY^=/TS6#AK52(>6!=);M15>1;W`+D&KS6X54F]\J*+/W[W]]?CY4CYS>_NC2
MC^B!1I=_+)N**X'T$=@J*+,__?;X\'1HU5/K&^]/7K$""2G.IS&E0C*<5H*C
MF1W,LY@:09*0DM0R6!FD]\=6\2IFM>TR7&C&L0U^G%YLM8&<E^R"EA3CL^)U
MS)+[6?5>CS4)SWO$):\`PWX]'^_O_OCK;W?9'%"N=P0@BY`DJF'%/ELK]FD-
M-0]LS3=N))!*KLF%(`,?),EHVNIN/ZL7A78L&>(0--S6,"3-SH!`!M;=#&:G
M;G_8FBFCL1<XW7`DS,JK/CND]\=609E]>'Q\^/G^P/8BK1JD,FS_>Y)SG['P
MHFP2KP0#9C^\>W[Z\#!=K&)X,[JS65H0RG?GLU6$Q0TDA>8"(,QJ=;#IQ]VX
MVKS'FN2D(,PF_QEBA\PFO'@5
MZGH&HF47)0Y>"2BS^7AF#22A^NJ-D\)+`V*TZP!A-J>CF?58DYR$2QZN0>\3
M5879->!US`8X>7>6-.?!6GQ.`N%U@/;%>WS\3'F^[^@=`=S^"[1^)K3P\7+6
MLQ*4?[A_^>G^\?ZW/;/_NGO9O7^^^Z\/$Z7)![52+>SU9I+.AJT%)"MU+:#,
MOCS\V_/3@6L]PWL]>"\\D_-9"UOV2<[>5P+*K/2?W1(FF)7^LYL`8;;MGO;K
M[K?/*'=]!)R"F]&IWZDP-F/=/5G/K@.4V4_O?GIX^N''W62/")J[:`RV).TW
M*HSI"GC)'M1*,&!6^N)M"(39[W:/#W]_?GF:OO5.8V.#M695K<)EL&*>)!RO
M!0-F?_[ETU%WWG7$4GR*UN!JS3@%LBT%Y[,IR&7I"V#`[,N'@PT/1[T_'&Y+
M]&L>J&:9)7Y:#2BS]T\?7PY=C![L&QL+1)+=16.[H$H,=!V@S#91\2\/AZQV
M,,_J(
MO@`&S+X\W3\>-<]FV%W,IJYZ,"LUUT8O)D,-OQ1EZKT`*+,O]Q\^'@R.Z2F>
M"3:/=BI,P$8I9,,Q0'G-7$L>&X]]4:)D)9\:`V:??[W[;O?TV_.A)FJU&[@=
M+6>5A?P9R8):#2BSGQI7?%Q?O&!<YV=K,6,H$65D=W$=(,Q*_]E-8<#L_<O#
MTP\'%$?K68B@E*L+6NA1EB0/:B6@S#XTB]E#EZ*'L3'>9B5MZQJ1Z<Q8F%T#
M*+//3P>SH(;K66VM[4YC:^$"Z(Z4)<=M'2#,2F?A38$R^^G=X\-QWAC/YTA]
M8Q.PO:&<O*\$A-G_Z_GYXX\/AS:A!MDRV/&P\HK-#9/$P:O!@-E/3Q]W!RY&
M#V-CBPU=:TM28S).O;*5N`X09O_OEX=_^[?'W^Z^O]]-S+3###<\$:CW>II5
M#]S^2+(+M0X,F'W^UT.U^49U*@)L+R;:*ZV9?.$`(#<+(-)"+69<Z/JZ?ZP"
MI+5*''TZ$&;_>/_R\G"PR=:P3H6SHSTHG:6/P+HP8/;#+_<O#[OIB790*U5#
M[B*IX`770?:IY<+K.D"8_7PW\%:Y9U9!OK$AI=B@?1JYZ:.25FC:,3@B1AEI
M09#'96E4M^=,/E=;Q/<BAV>"Y%DPYK(GSX)]S^Q)!WH\<K2D?RYV"25-'#,4
M@,U4`INJU^"77L>L!V\[1D/Q>Q]
MJ,F1+BL'-:A<BHZ(P5?4AM':PQ#SI-VKQU!>T>=!#14R3ES"XANTF2PV0B:B
MJ1;W("(M[BV,@>D6][7E+"B1(6?[YLE5TKX+2W0@__=+I?%>Q:S1&?>-ZZ)G
M_&^C<I<K9<C:"$VJFJ?9+XYQBLZ!:`8]NA1F3!R;>[/\@MUJDK9C\9Z@JQ^T
M,"@4N:UBO8,^88UW,.1Y4.]5;6"[Y6AF!_UGLS4.;]!:3YR5!2>:&HH<D488
MG"D;*85[-KR6V8[!RA]6,DXY!\*UUEUVE#!Z7KR26;#8E&G=1[)
M+&P^)!):PO%LHH$DQK?"]$7P*F9QA9/H,D7YSF0GUA'"[?GQ2F83JV:@8/&2
M,Q6%KG3%Q*)4V#XMALRFXU8]RN*RM*X9FQBYM="@,Q$E$-4XRSK?78YWBFCJ
M%&')&7,@J:Y:XWHU6OI5F$[G@Z7'_CC3^V897&<)DT+"GO2Y5G95S0(*TD*\
MS8IH^PR;WUX/'F*Q9-TU>9_7,1OTN/.'"FI\BZM9/H;1KI'RL!+/=3>@$8$9
MDXC:HV63DN?>!M@*2=G17%@5840ELED!$T-R=>'EX&L3J;3MX&L3:=KH8%,@
M;6/Z>!6S?0,7LI>(!DKG7LR62JEV&\!M!+J-9#7>GR:;,PIO67LB@C45V:8T
M"3FMC\<.4:GN4FB#2VRRK8-5-I(FW2;@#XKD1V@8JF07J8D)8><J-O^3;'MF
MV(^C^ZH6M]^R)C?%%?BE<)Z#SM<Q&Z&^L29M-R)<L]3UJ*X1&1#1VD(@(DU#
M0M?[1VM/WE>(L#[6VEEZLUZ#L+(9\+(T'
M@2IFRIOJ&[3W&:HBJ690UZU&+.I,:[,[V"BCS2!A4&9+=QK!P1FZBPCQ)E&"
M@?#:*>!5S':59&)]<<8H'*5U!T]GF'KK74P#35U"]<]&P[9[B$0$#12#)R*<
MQ>E1/VP9DEG<:(L3._D@;F>3C"TP)WII4..\3>XD8=^2*TXD>!VS$8=A'=4&
MRZ=FPE#`&GZ!7.*"SP6B!)SE:@F-_X1A3Y@->/KKR*.P]J,EOP&J>F:R$1SP
ME];^,TV4A+-X?1;,).2(=#,ZN@O,WT<S
M.]BI0#9H:`0S7*99%C7,NM)A?]5X';-!8Y?2&L\&JS\3"`NU9\>KF-7-XA$F
MM!KW:4RJ(#O),,WN3UF%V//C=<S:/IF-Q'9V=$BP[W@IAP07PYN8S98P&WWN
MXA=+EJ81XWNR-,7>X33DQWP93408U9!B8OTJ.HVUI*HRQZN8G8H<O1/[7!4(
ML_]E]^ZGPT7<!C7)FS"_G6?[.37!IH242ET/*+//O[T[G$D^8!9WC4*]&:TB
MN-TK7MIO#(39?[IO_OM0(OGP+I['+312(LAW095$PNL`8?9/NQ\^';X:/6!6
M9=RJJ'MVT%E86%T-!LS^=/_CIY</T]7YOGMXJ<PF%PV:J"+5OE+`/)JL;)".
M3)?%B-D//SZ_3,^U0V^<,%NB.N.N9X2$4"L!9?;AZ?WA)EN#^[.IJT"2B+U"
MMO95W(RX!5!FG]]].N"*[T9W\8)""R5'E7B"(M4,5@+"[#_O7@Y=>+\;>>/8
MY1O7JD%P%4>*DJ\&0V8_-M3^Z=/''YO%SS_MBW[]E[H(&E3!C9@,4O?Y&A'6
M))=5SSHP8/;3O]R_''+'@RZE6N.D6B^W=5&Q5)M?"2BS[[Y[_'0@,AXQZS#_
MIW8\;$1RYWU5H,P^/'YF#VI043-CTE/-$E$)#F*\$YM=!P;,?OAPL$'$H)J!
M4@K/>G!W4>]M%;8NQ&17`L)LUSWZ'Y^>&M/]X^[E7YY'%EQKN&%V64W#-D%A
MYGX3,"?9?[H\*+-/]P^'N@@,YUD50X3SV&!<O<.OHL,N$>*1+P_"[/>[EY]>
M'M[_,!U##;JG.4CL)?6@M#-P_".(LKA?2GI>+@2
M#)C]</]\]_WN_>3*Y_N??OVM1E!0[C;87",HN+-B)():"2BS][N7P_/LL*)F
M0@.MNXL6+LL&+7/L.D"8_?/NX7'?$'Q:(KAX)RTB
M+H(!LT\??GD^M+LXF&<S[O_7`UJ5O>14K`J4V?OW[X_K_:%SEP=5=Q=SQ(O+
MXHW7@2&SOSX_'RHW3W<7NZ)X]))HUU=`3O%6`LKL\[O#K3^&WMBR6ZG*PO&/
MG.*M!839O^S>O>Q^OG^:[K,UB(TCWGDF6:D1[GYXZ[N'UZ>
MGR>JS0_WH+IYEA0?[:Y_D&TI#YD7<DIP"0R8?;K[ST_O7^YW'R84!]ZX+Q9?
M;T$[B9_6A2&S'W=W^VRHJ>EV>"+07J[\].Y`AZUA
M)Z;$.AZB2#H>K@4#9I]?[A\?GKY\UF,"5/0A)P)=V1`Y#U@+*+,__7:0UU&'
MB&BQ3D6M_81=M^2H9RT8,OOK_<%4\D%LK*$4?"!%T*3YQ\I`F?WE[O.'`B2"
MZK;_:VT9%&699U>"US&;NX*GE5EHG.')-?B`=;"\][+E>'Z\BME]U9@\KI;:
M%PBAI0,U=A?(+DASB/.",OMQ]_'^[H^__G;73)K3RLBL55CREA0JS-BEJ/;8
M:41^7(LO8ZL73T5`/9&D.*Z[US5%JO5H&A$\BGPNLK48;'G6JO@F0X)`HC\3
MZ^@ZJ@6[9^Z*3Y:GF9TFEM1*Q0)!I-IL;/B`*FXZN;KIF`9[58V6PCJX89]]
MT8L3UK@U1`0OE]2XC5V-6_)!V"-)EGP%*-DK)F413#)K;)I6_KJ;9_LN8OW!
M.]:?5K2&V[B@TT3[@:XW5\JD\*I6%NNEIF;P$&V'NR&DE#!*OOGFS"]N]3B:
MV4&E+Y-&MHA]A5,M>-N(0E>EY+:-YT(8,/MI=_`JWO`4S^LTJ`=EO(JC8-DX
M*/4L):(N!,+L7S_]<O\X>3:[QU_O:P42Y3.N<H(F26X^8K:JS_N`2/B\*`BS
M_V._`?6GY^=?)A4'=_$\5L0GE;X"7,^33:BU8,3L_<O3W?>[=P]_?WA7%[=_
M^>437-VJV3)0!U^1YAQ=:?P@NQ+K`&7VX<.[YZ</!VI5#',7.V9K!1+,7:3M
M@3,N@[)<S;L`*+-'[T&1PJ@UA,+EAYCL2D"8U?GCCX<5!R?O>-6#E*DVV&-K
MOWP5:M[3?E,&BHE
MW:59"+5K`&'V/[__3"+YT&:QV;VEW6S`CIU<$E@)RI]V?]_]=O_QX_U7W^T>
M'_[^_/(TF;HX9%99/,.K[ABK5$BZS%HP8/:7EX=W#;63BH,(2D<TT'I>IJ&B
MII7J(RL!9?;'W<__<O\RE49^-\I=Q/-96X]9-5Z\M$%"J'7@:&;_M'NZ)\QJ
M8#:/=RILE'EV'1@Q^\O!4E^#>5:/NP@W$KQE*2<!*P%E]OGY\6#1H%$?`3BT
M4YYL)6)BE`10*P%E]N7^P\>#U?GH68\)-G<66CN$VG%J%![_Y$CZ-6$V1I15
M[ZE!F/T_'WY^/KQ7,8R-NVKS-#;&A9`8[3I`F/U#XXE_W7T\4"YU&!M#`!5)
M4Q=HLN4D?EH+*+.?WC7S["'%X5V\B/6-*[4!#@FDC\!:0)C]X_WNY>/!&B2C
M]6Q+HW5Z'$%9*^O9=8`R^_SX^'!@-3ONZ@+=H"TYQ8/RQD[+%M1*0)C]Q]_=
M^<-=2EOE/H+"3/+JC,WXWT;A=8#L3;UE:ZP995X8TXP&W'+.@6@&/;I>8@Q4
MQR"]9(R%\%N9&I%;2%57-<O=6`<I('5CQ5CO%-2A"\Z0Y\$-%K6!*67([&>(
M'?2?S0'C)4L.:#/L&Y/;&!X#+=F]N`!&S![963AV$52EL;4G87`]H,P^O7_8
M'6S%-.C7HR`0IN>S"HIL.BWKGG6`,"M=2C>%`;/2RW)#H,Q*+\LM@3#[S[NG
M][O'9CJ=Q.!$P,(JAZYG+5SI<9+AMA(09K]_>7[W<=RBI\?`&QNP64<J:AI<
MXLB]GI6`,/N7'^]?'MX?BHX'-FLB[#B13N`&$HY=O=]LL-J\C1)870"4V:.K
M&31+G);9NII5%MKU[.L<U,O1V%%-&RI2L).D=7"LHKDLF9;#T<P.=BH,;-?1
M?3ECNWWC7@(Y-383EPW'\U;JXIX>D\P:=T"YGN*UI!E'$BB@L(0A%5I@,C:A
M^N(!\
M,Y08M*3R3(#NJW0P!HTA!?DQ&C9ER/YU4+A/LYZ-5,+L7W>?7CX=/.L9YE1X
M/-FI;T`;?$]2;7X=(,S.N+$%F\2UT#R[,9"4[8[FA>?+@#";T]&W+#'?V-#[^
M\OSSW</]_WKX^)^^>MK]?*A4;O?0CS_>_[+[K`L0K`5ES^J7E+[ZW1?Q'[ZL
M(E@+CB+K"QD;[9JJK1"G?P]N7=F^TWBT4$=,65M%";6,5&^[!`JGABL=0_K?
MAJ2[GF$'74B&(D@+,'EJ'/0BG[H/2F"P*`I_Z5QICJ4G9[L+O-_V(H.UC+*O
MK7+W8CA=]F+OYT69)F:H-,?24U=YV5=V/:;:F2G">Y'%TKYDM&#M=2^+@$51
M.`M<:1;I60].FEO2<3A1*W>H%BP1]DY".#XE"G_A7&D&Z4E#F94^"78O@OH<
M2KLJ@F,O);VR+X'"B>%*<T@W*G0))&/2NVJQA'0ID74)C$EOB.%*,P*YK`PV
M2N])SPI[\QI31;#QOH_?)8@[.PHGABO-L/2LNGF"D@[&KVT5F8"5>W1T1-H/
M&+'_$Z*2'E30T8:(Y.N0HG'>-V'8-[-(A^--9>*46?<BO/XB2_!+H'!BN-(<
MTK$_]_[Z:L>P[2)U342^6RP(ZV='X5QQI5FDAV%SG?;96"Z"D`[I!#E6X\?<
MTRR'Z2='X2QPI7FD)T9Z<-B@):6ZS9JMQ]F?^`2O,'E<64_<0G]9H`Z:&'I-
M.I;X(V4L,532K0K.1^?PYHW5)FN7LK?A^#G=-$$8KM-UGV*D#"9*U/RD)F3`
M^ZO"Q`50.#%<:0;INENGU]0PW3T[U:9;&DQ?!=E\NP`*)X8KS2'=8UL74\OV
M>4A.];6EG[W$+L;J8B\&A1.#5>:8>G-@R`S
MF20_PGG+0`+QO*%M*6#YH.6TY?0HC)@)I3F6CD7_2!&3@'F3)EDBU""T-%$<
M?(0EB>(0MQM'M/"72D^PUZ/PU\N5CMY[/\037E2H=U`"*DG^Q"50.#%<:1;I
MU1(YP_5RBA;2+X?"B)E0$O>^+13^+KF2N/=M80E+%_=^95B,]+]Q/B=NG(I'
M7@,*YXHKO9ET#R(IU+(.+$9ZY]XC5-0RY%IVA$K\]#YW@M,TD\C]58TB0T3X
M09D$%D7A+'"E.9:>8%?=1#_!72^!\TY#[O`GR-<R47;D3H["B)E0FF7I&2T]
M<]+M%.MBQ&<'(_V-IVQBZ5>`PFG@2D=OSNC?!Y.BAUHMSM0\N6"5@HN,UL::
M*Q=\#`G/7E3*59R2B7#^XKVIXAQ,`+$U?1I-""I!!TR=LI<]FR^C3+_]H=(<
MTH/#/$B=:IY["$8EE(9LJU@G2*'1*3IA\5PHTZP,E6;DR!VV76QD.A+G'-&D
MH_:$=>POH',@4NV-P[&0PZ$!)4/DBRC3I`R5CK'TKWOWCFT0K:7LFFQ@?]8V
M_]U?;PC.69S+^]*-^Q_C;,13^5@O3>S%'G]C-):(LT&QM_K0%"'Q8D69?G-#
M)9G3MX4R_>*&2C*G;PM+D#Z8TT</JD;JL%!KULK3J5YCFI2)1#MVQ5ISL/F0
M(Y?!\$J4:5*&2C,L/8);5O5:8C0&;DQ5"V]$%LO.-`.CUJ<P&DO2-?]=1T;4
M4"-#U\L.4[H7T@
M4JB!HTFI#`7E1375@N*UY%YF5!;K$ALBBDR$$UJL?WCW-E*=#[/':8^('!)7
MC29E#(EJ]!1`I/<7R<HT#?-)__HPZ?!F^K3WO0CJBBA2D`1;=9&J)49GO#B1
MD\]$#"01`0X4,S4F)(#C*/S-<24A?5LHTV]XJ#2GYDRWP%;4F7/1\.MD=CXK
M"B>&*[V5]&K7PNX:4#A77$G<^[90.`U<2=S[MB"6?H,HG!FN)*1O"X5Q-:$D
MFS,;W9PY(>D1NYR3`L_P3I63-)E+8`G2AX$<)QU+U"4JLN"353+4_D$6(W7Q
MH$:\>?/L;G+P(\E2*JB!]]%
M)2[A\PPM#^U5U_#').+/43/:ZFU=PE)I]</.XT=)`7J;F`A')14I!_&$,I[,
M/K;Y\[IOUJ2"/59"-?7'V-!Y/6OB0`Q"T@:AUKH_@7<L_"?.)GU@Z4@O<>7)
MY-2]JD#?24)Q2&'J58G!G@IEFIJATIM(=PKK@4J=P+6@C+F:4A)+WQ:6(+U]
MCLSI5SBGUV^93;IT:[HR+-:X1[HU70\*IX8KB7O?IGLG?^-LTH>6/O6R0*03
MMW6QX@N@<&*XDECZ1BV]_MFS21]:^L3[:PC#-YA(C[[N#=JZEXKSNARPGQ9E
MFIBADECZ-BV=<,65YEAZA,8]I")_C'BV2D7UZ\2HSX["B>%*"Y%.C%](OR0*
MYXHKB7L7]SZ&N/<KPQ*6+N[]RC">TU]MZ=(__7JP?"MMZ9^^>A1.#%<22]\6
MENZ?'E/&'IN)6#I23@GO6G$&2X3];Q##/B4*)X8KS;!T+!2H-.F57ENSBT6O
M`N/^Z?J->^^IZ\"HXA3KO2AV"W<QZO-C"=+;YW2D^S3>G$G8GX]:O^NTB"A8
M)O)<"[='!B(W%EFGNE/#NAN43,84S2K!-+UZ4289BXW=5:J;):GK*ZDVD;I7
M^%_%E>:Y=]\]:&SI2JK_K@-C2W];,[[AZ)D@?>S>E;CW"V`)TMOGB'N_'A3^
M?KG2'$N?8AC,FBS9&E%@(A]&E)#?M($WO2(L07K['+'TZT'AKYPKO=72<W<@
MN84WM@$43@Q7$DO?IJ438KC2'$MWWLG4O')(('>#*)P8KB1S^K:PA'MOGR-S
M^O5@^3E]@CNQ]'5AB>A=YO0KP]&6'HXD/6#9B<I=1-=H-^$:MX#2,Z.#M<V,
M#%OPQD2=O/(N--/=+-*C'D^<$6]!.\ET6PEZTK6*P=F4.]:]L5EG'?8&.L>]
MA\P"N7X[+'YCQ2_
M$?>^+51+;WQYTA;[J#<6WRQ>@U5I7XUVCGOO;KB0A+AHS#A41U^^%\E`.#L*
M)X8K?<'2V^?\C=MUQW""JW>V7F-H1.W0L-(X^Q+H27?*VX8=#1&6-MD%ETVR
MN0G?YY">0ON`6,M$I03UMJ.KQH^9TLWT48T?BB+$I,<18)(;+LNB6KIWT603
MX-9MLD$K:W0P(?JCW#LF1N8F[@?WWN?(92QNKFIE]ZP\WN.5*OP70.F)"2KH
M:$-$@G1H!H+SOF%QSIR>57=-A9(>1JNXYJ&ABQAKD7`Z8,2R3XC"B>%*,Z+W
M#'>00PW:LH+8,-0R[EEI\.7!I2P$GQT]Z4XEYU170#\T4[K13336#(8OSNDC
MTEL+CHKX(#SK9!.<N8=\&W=K<4*/CK&W8K&!^
M""J/W7O04BEP'2"D-S%;,Z4'L'1M7<P^9:O-%^?T]CD=Z:8[W>YOGC?K_U$Y
M\(RW'(DSZ&Y5$6<0</&G8Z92F?7?C,)>YH32K$`NL.#=AZX0CR7F'SJ9T'=N
MG(/T@&VKE'$Z$+'N5@K6:B*V&H>#ECNMI\$2I+?/$?=^/3B/>Y<$F%5!YO0;
M1)ED9J0D<_JV('/Z#4+F]!N$S.DW"%FGWR#*-#-#)3E/WQ8*9X$KS;-T#-+B
M%,.]*(*6',%<`DN0WCY'HO?K0>%OG2O-LO0)^C!\5R1S!HO-B:5?`H43PY7>
M2GK4&>.%H*F+'S??;$1]8PL9#*?#$I;>/D?<^_5`W/L-XBRDBWM?%\HT,4.E
M.>MT"[MO.572L;E4CK(H7P<*YXHKS;'T*=*[+@Z:B%!+]MPN@,*)X4JS2*]T
MCDF/$GVM`X5SQ97$TK>%)4AOG].3CM=?4PW/#.O/URSL^D820OK943A77$D"
MN6VA<&*XTBSW#K<E<@J$=&BS%_74./B6#SLQ_M.B<&*XTCS2$R,].&B@G%.J
MU]:S]7B_E?@$CX4PE+(T$`SCZ<%:O(JSUZ1CB3]2QA)#3[HWV;N0E$$+#"9&
MI;3V^AN9TS<&F=-O$-6]6Q6<C\Y!2<]DM<EZ?WT<RX_(G+X=?-&]N_A%]RYS
M^I6A3!,S5#JFT%#OWEM/00Y6+9S`:$=$L?TJ;2BQ!IHLMX4KJ9-(P'@D%]XM
M)MV%1%T'L*N"MM1]1"RQX0,IB-*,!%#V6A&I3I@GZ$(DXF;HVW$*F`FI[3A/
M!-A"/(T#ETQ"&07OV-5?V'QG*[)G[$1;+5T%:[Q2T!19I>RB33Y&H_V<ZE+9
M&#@%MSR0\^05`96:QG89V[0VKY@<O)D<H%2)UI3+A@`82I1W^.UZ7_*4.`]0
MS)9Z'BA_;-1`#'E[1F_>)]0Y/304)XNDZ]#8>^/P?0H1B@>F8Z-W>,F)O$PX
M3D^&>&???DNB/$(PD;0=&W1,U$1!1"J9&*A81$<4C#M?NW17D28B!S[(>Z=O
MJP(*F=/W?WO$BF+[G/,8&P_69DI^@?1A]`X,V\@8;F9I"=Y7`4KZGN1L.H8:
MAQ^;F;()Z+]DZ5,'+LG3\`J,V$T.A&^9B[@EH[L(!J3;)F:'XE!I[^Y3,_GY
MYO_FD0X3.#U9!3*]&4LL#?`-'P29S0IU"I"!\080TO?5I1K>$U"DHC:N">.:
M0';6.MU#$A1=LGD,;.4X?24HC)@)I5FDXS+=">>KQ1*DM\]I23?[Y&385,>X
MW.RW3W`15_U[A+@YDQA_8K!4GR&C95$4_H:YTBQ+#T9,?>40]WZ#$/=^@RCL
MG4\HB7O?%I9W[[)D6SW$O=\@"N-J0NEH2]\_J&O&9WK6\?2P[UT\^#KA\_PH
MG!BN]$;2\12YO[V\%V'WMMLZW5H+"N>**QV=(]<RC&DN<8IT.69;`PHGABN)
M>]\6%K-T[$0A2+TC),!&DUV3B#6)R*3.AX7KX
MC;J7A&1P>:"UK=-,P$S?FT^V+_R%<*4YEDX>U+]L<.99UW$0(.LUBZ5?`H43
MPY7>2CIDSF1#)""09(B+X&A+/RHQLAT],%MW586(61,'[*$56$YU(/@$VT,A
M$A$,CD`^B,GRNLX,WG:]0K.+-6SP*F+NC7?5Q8"BJR/2P=<F'8G(#G(T6Q%D
M]FRCDG6IQ/@8C-4)+3[OT^0:09<"?52Z5'49^T+?U:[U9QC>P$N\-O2D6Z4;
M^]--"`2D>Z-3CE8U(=;Q?=DDD+L*2"!W@S@+Z1+(K0N%$3.A)'/ZMD#F=-/,
MQS[CG&E,;B1I7_+?R9R^,13^TKG2+-+3F,^,1_6J.OSVDAP(+1%:)G(HJCXB
MXV5WJF4-%BU3UF]B375BE.D7-U2:,Z>/'E2)@?OD*0=+R+[1'A)
ME$E21DKBWK>%PKGB2O,LO1L\E72#=Q,SW5LCWWC;%)P?99*8D9+,Z=M"X:^7
M*\VR]`GJ,,.1K.+(UPE'9\<2I+?/$4N_'A3^QKG2+$N']Y]R%+->*\2]WR`*
M)X8KS2(=:LXDZM[A+)JLJ3)6&!3&+X+"F>%*,^9TK16VW^HMO1%AAYY>HI+&
MG+Q]V3@B1EF5!%A:YT1$F))!/H?>)9%O<%BEDCP+RE!E3YZ%JWY??ZR"FG%-
MZ%"'*&X74$^%U=^HI(MEUC^0"__#N-(,2T>"$V5)>1:-U6];_RO:'@IGABN)
MI6_2TLG[GE":9>EIV'FOI0E>2*8B>-O93#&W_M=VW:BD^V2T,\EC(7:#_PQ>
M'U]=:IKTSJIK,N.4/VB6V^@/A/,3H[!7/J$D[GVK[MVGH$U(&3*8-:95>.7#
M3$MGQ(D)KPQ?=.]1SR@>*'/Z5:!P8KB2S.G;0N%<<:49B9&ZF:3W#PI)$[/&
MBN\A>)>I&(5$I#I-G0)Q`@GF]N"33>-Y.]AKF$?7A)[T:*/9S^104R#$9+/3
M(6059]UPF20]*J@M'8(C3$84T6D`',"><B?<G@R4]'U!?^6`B^BB5=DXDYV9
MDPTKT?L5C,S"N>)*(F33:>U"Y<7X]O4V
MQ!(12"I3!INZU!RM1@0CC42/363:BLC8T'!7L8DKJPA[OA`E&%/*3<8DZ^>8
M80G29<EV95AB<T:6;%>&HZ-W6;)M!X43PY5D3M_HG%[_>JXTHXZ<-M##425"
M$@ZH9*6.W"I0.#%<:8Y[[XH'IC1%^H2%7:&E7#N6)UU#';E:_4487AN6<._M
M<V1.OQXL-J>+>[\>B*7?L*63=\N59EDZ;&>KG,G[!]+)YCOYNBM\:=>.PHGA
M2F+I&[7T^MJXDI"^3=()5UQICGNW<#_*Q.K>;0)1D!W6=:!PKKC2/-);<S7$
MG,BSA?0UX`2D<TL/$2S]UFN]K`5BZ3>()4AOG].1[B&S,9(PRT-E[D`2G#P4
M"`^^AF(C8@K#&:![RMKPU1-3&
M,E[1Y[4_Q)%AZZ!8E:MER9L?`B(2G3H(%"W]N5`#U\;Z([!#O8W$*EH[L9XH
M0:4U2_*X+!39K`79&DG[+BS1B?`Q_?D]K\+59Y,^LO3^0?6GP%]><\P:4<N(
M)0DVW22099/NU"B<&*XD<_JV<)9`3I9LZX+,Z;<\I]=O$=)OA73R@V>3/G#O
MDW]Y'/_E#DY;I_]RF0-.C,)9X$IBZ1NU]/IG">DW0WI]1=.D']F734</9V`D
M&S;"_3@=$Q$9$-4?'*`<@C;U3P\QHE![,F)"A$OT6COKB52#L.X&!/PM1*#A
M[G$%L`SE:]'C*I^DX@4L?B8P)
MJ%!NZ0#`ED:4W%$/G(9<N"ORRN)<I1_QQC0O-@4XI/0VFWU!0:7VG7+%TK=J
MZ?U?RI6$]&V23O[XV:0/+CMX`ZP0+^WA9?C&8\EEAS6@<&*XTIPEFX?Z`][D
M*=(G#$P6:&?'$J2WSQ'W?H7NO;(PF_0I2P_DE7F0^#S%N1CZ^5$8,1-*8ND;
MM?1*C)!^,Z17KMY&>H04XD12EB-L\49R_R$J!=LS,4=2^*<9%QIU'=T\B0:(
MB,DXLDD3++RN&"/9`PG-`L*!6.OZ9@.4'HI!8L?"7PE7$M*WA<*YXDIO)=U`
M:TU"(V[#)BU=E2^`LY`NEKXN%$X,5SJ&]&Y'+GJP8;(C!R%/LE)]9"4HC)@)
M)7'OVT+A+'"E6:3WHZ<G&$X&D]1V70N6L/3!CAP9/=^./;Z9\/@R#LZ/PHGA
M2K-(QS[LED1MT!N=5NV.L"T@K%\$A1/#E6:1'BTCO8X#87@-*)P8KB26OBTL
M3WH-V[[EQB\,KP&%$\.5)'K?%@IGABO)G+XM+&'I`]*3L6/WGHS2T';71E]W
M49,*<!*8K'=DWR:CT'&1^(I%4*:)&2K-(CURTN%8/!%F$Q3Y3V0G/4$9J8$6
M),PGN>*\+`HGABO-(3U#73!RUP&;.B92D2M!C9(]YT+G^5$X,UQI%NF0`)/(
M=98<G(<A%3TI4)%QJB>W13)D;:58K3WC#I\<CBV',DW,4&G&*9M1!N_@]*0;
M9>$23HWH#?;[?RG*J9BP;;
M;F9?)=%EE`5%/@\1`.FB9Q1D"6:I:/(:+$$ZG=,;2X>+F)I:.M[-G#)TX>S\
M*(R8"26Q]&VA\!?+E83T;:'PM\B5YI#>K-G:!_6[L'"+E?[;**0V^]J,SQCL
M?UOO[!OCM,-.C3D0S0#W_141Q7&W3V.Q5UA-UFN^`6MXUP]:N">AZITK8[U3
MT'PH.$.>%[`CT?4/L\*XFE":,Z=KC^46J@'KB`TU,Q%A)TY=1<EZ_`TJ$G&V
MW1!1=9%/?N_54W!^%$X,5YI%.IAACH0@'`:&2!Q4\LC)&6'RW%C"TMOGB'N_
M'HA[OT$L3[JX]]6C,&(FE,2];].]DQ?)E>98>O?Z]21)5_^^-H$E2&^?(Y9^
M/3B!I>.#M%CZ6B&6?L.67O^D":4YEEX?5-_KN*>AL=#D4TFZU$50.#-<:0[I
M#NXEDPZ8!@OP*+(H=UI#E1S5K+ZK:;O:AUL&P^E0.#%<:1;I4,58F[HYXQ+V
M4)4Y?1THG!BN-(]TK,`MI*\6BY..M=JT(TX[.SBXW9=5(RX^H4_80&AT72C3
MQ`R59I$.B9%-$-^SZ['W=:U2;[S&NO\2R5T`A1/#E>9DPV)Y2$T".0\UH(PD
MOJX$94S,E-*<=7K_H)YRZ)5AU"M[3P@6QV*DBZ5?#PKGBBO-L_0)TFTG$EM?
M`Y8@G;;SH-Z\.GB0>#'U=:`P8B:49D7O<+W8U.*!Y-G5]A.(R-1?1YVX@Q-C
M>=+A+JHAY^D>F["10Q=D74N.S"50.#%<Z<VD.[9T%](OB,*YXDIBZ=O">4@7
M2U\5"B>&*\U9L@4HV$ZR(P+LQAM#ZHPU:B"T-<@/N)PGM^`"'/@:LF,?,/IP
M<HOMU2B,JPFE-Y)N'=37-]:2W(J`8;YU*1!*/0B)"%V'7&M>#.<@72Q]92C\
MC7,EL?1MH?!7RY5FD5X?U-,&!:>,DR2*=6`)T@?1^Y23]BC*4^9;AT9@#A\<
MA&19+(S"B>%*>]+SD:=LE:C*9N?<IVQ?MN//C\*XFE":1WH:GJ>'A`MW/V'!
M0ODE<#3I1[MWJ/UM2)9[8]<*'N]MH/Z\E05)KC@W"F-@0FG.T2I94M4)'"3$
MU.'NTUXDMGY^%$X#5YIGZ9I3+-'[JG`"TF&=[GA<3H=!/P?(,#@_"N>**\DZ
M?5LHG!BN-(OT^J"Q75-10L<B>>\7P!*D2R!W93A/(-=/'6+6:\#1I,N.W'9P
MM'O_$NF?G=/1XTNBZSJPV)PN[OUZL,223=;I5X;"B)E0FD<Z/"A2]PXG>,$)
MZZM`X2QP)3EPV1:6)SUC<$#"]X0+]2R6O@H<3?K1T7NWUY:$X;7B!.Y]8DXW
M%D9"LM3:0X;.3B8;+=NQ9T29)F:H)('<MC".WN/;U^FR9%L[Q+W?($Y@Z>+>
MUX["B>%*LD[?%F2=?H.0=?H-8@E+;Y\C.7+7`\F1NT&<X#P]LAPY9'A@_'TV
MC9!^=HS=NUOJE&V"=#'KE>`\I%N9T]>$HTF7Q,CM0!(C;Q!G">1DR;8NG#.0
MD^A])2B<&*XDT?NV(-'[#4*B]QM$X<QP)=F&W1;&<[I[Q7EZ^YR.]`B5A4VH
M[CU:$)'.Q9,'L![Z*C>_@2@F8W'(.-(?60;-6[`$Z;)DNS+(DNT&(='[#6)Y
MTB=RHY)AMY=E3KX@9$Z_0<B<?H.0)(H;Q`GF]#YJ(RMP<>]K0N%<<:5Y*="8
M#1NFHO<#>RXR%LZ*HTD_WKUW]U;&E0*#&/I*L%CI;[FU>CTXSZU5N<"X*DBA
MH1M$F29FJ"07&+<%N<!X@SB9>Y(2E
MM\^1=*GK09E\Y2,EV7O?%HYV[V]*HJ`#2GB_.):P]/8YD@)]/9`4Z!O$6=*E
MA*%U87G294Y?/0KGBBN]D?2H8$!Y+XRO`LN3+@<NJ\?1I!^_(W<@\NISWX7E
M2Z-P4KB21._;P@EVY.3`9>TX`>ERK6GMD.C]!B'1^PWB')8N[GUE.`_ILB.W
M*HA[OT$L07K['%FG7P\*9X$KR;6F;4&N-=T@Y%K3#6)YTF7)MGK(DNT&(=NP
M-PA9I]\@SD)Z[IP[&0=X^4GF]`O@Z'6Z7%7>#A;OM2H[<NO'\CMR,J>O'F<A
M7>;T=:%P8KC2F^^G]PQ74=)@Z\9Y,OMG94"LO:>C!IRY)EN[N7VFSG3*L""2
M@?0%%$X,5Y(Y?5LHG!BN=`SI7W^&=`=S>JB&&K$39^4<RT+'6FDRHO.)U4$D
MA:(
M4U=>E#P)=_$#(1V(
M"#\H?"Z*PM[OA-(LTC.2GCEWQ-(-F&S2PN?Y43@+7&G.DFURVNT&U`3G$[.N
MA&8GQA*6WCZG(SWCD1H)O[*"4#U6UK/18X^?<;&6Y?3UU"B<!:YT-.GZ]\US
MVJE9:;3T1J13&\@I0R0C@4H1/A6K**B,LDRE($LR,EZ/TM&0C?+&JACP36>;
MLK?)A88])/U__\??A2GJJWMO26^C::4JZ4:!J-M;@:\#4>`#0=@\-0IG@2OM
M29^DFSX''V3;04/LW((1:T=$D#&K#1$YX^`7Q.#JX+`VP6I`196)%/Q"EW#7
MBC3$"2IH2S2;=2)\WH=,M`TJ>ZV(5"?89%`N1")6&@>RJ1YGOVNT_TN)H)W#
M,OD6`UL(.8R'?W:9C/7V*YL7<+Z0MO0_IWG7.?D(!I>]CFJ_T9+W7;2.(;VS
M=`US>J3N71OP']&%1'R\!F&7)+L7F?8-Q$@<`&SC9.(Y-&S!9D]>N8+WF\3M
M'X'"WQI7FD4ZF+H/A-W6!CSAUK?6YRW1`4/Q.H_I]LJ-I@"7JRMH#=998EX*
M161ZL:U].?(@8^%)MSF;5/?>6'D39R=89CO7^'OGE;(AFR]9>EVGMSX-7!HU
MS,2\7!J;JLX9/0QA&,:AD[7\PB#N/306X3),MSE8WTQFC2B%.(]T!U01*S8:
M!H(CEJ9ZD1!Z=A#2K5$Y18Q'!D>LQY#>1^\3`0V$:#D1K]R,)AA=,07F$R)U
M$_`X.CE4#S`1#=V@MYX-0GK2J;%T"'9S#*9Q]G9_L'F<I7^6='#=1&(PKJ7#
M`&S?9^(AW)AP`^OT[.*4TY`Q<!RHI4=C<7'2O%1K?&P$S1S_S=VL=;K#=3J9
MPIM`"U;_*D;"J64;,LT/@+61&8\/9<@'#3S-RM[=ZU`X`UQI3O2.BU.EB7EV
M^RYR:VT=*)P8KB3;L-M"&=,PI72,>^^C][K@G]ASE5!]#3AZ&U;VWK>#PHGA
M2K-(-QZB+#ZG6TU$N)M-UVL.8T"CR.Y[HVG0I4>)W);!>$ZW;YW3K<%%>:;1
M.POH:[@G-)X=A1/#E=ZZ9(.-[H''1W^@Z)F4QQ!0R4@X+0HGABO)..GU;.-K2
MCU^G$X,5;[Y*E"FNQDHRIV\+B\WI7X\B0J.G_+BLT]>`H[=A)9#;#LX2O4L@
MMRZ4:6*&2K,"N<K(>$ZG.6V0[JCIT.C.SK6VE.$<@@8QS7?$*\W:T=Q(N-&L
MHU;UFZP'19)B98/#A&\U$.,=2KWYL50X5UQI!NDI><A1J\::$B2[N7KBG3)F
MLD4B\2`Q1!1!1#Z7,-_.5Q&D27I?Z5/P01^DAMDD"G]/7&E&$L4T!PE$U2H5
MG,4)+1=!X[]:">IR?CO$D6)MOLC&KXMCXU
MPT!2H#>&PIB94)J5&,E(QRVZ0/?CP%2EZO=E4!A7$TJ2`KTM%/XFN9($<MO"
MX<L."F&UW'#9&`HGABO)98=MH?!7QY7FD-[=/:?[H[ACZHBDOZ`NK)P?A1$S
MH32'=`=IC):LTYVQ(*KCP($1DSG`9I20H9'&.E!LSFIIR/TFE/$+GE*:13HX
M8.TJ5U#%E=:'$$._*,J8F"DEL?1MH3`6)I2$]&VA<&*XTM'%`_7O4PC90R:$
MMJD>@,;F7Y@@$91LD%\6I2-%Z6`;EO`B8;.FTLDK[X)VW\PC';;0R!VFAG#<
MG-%$!-^CJ,AU(AD2IT7IN4K1ZJBB18*,#RK'_7^DHT[9ONY'#UQ"JK5_&A$D
M:#A)C%P'"N>**\W*G($6JM&2S!GGX6"U9L!@5=)F4-6A`5E1,>FQBT@^BO$O
MB<+?+U>:DSD3X29DRI/<=:(`^6@IRJ+M`CB:=`GDMH-*>EN?,^4NDO/&9IUU
M4-Y\(X'(;0R%$\.5Y@1RY$%]U`97&&S-
MG6E$L"T@)?TO@<5)E^A]_2B<*ZXT)WJ?H#-!NE2L^4WTZX3.LZ-P8KB2N/=M
MH7`6N))<:]H6"N>**\UR[W7TC,TZDW$`%=C)OX%R153J+Q+FEL78TO/;2<_P
M(.+>(5?29D(RG*-*9Z:+H'!BN)*X]VVA\+?)E6;=6F6T-!SHCH/*%#3]B)IH
MP17*2"K&MM[')XGVED7AQ'`EL?1MH?!7QY7F7'8@+WSB?KILPZX!1]]/EZ($
MV\'2I&<L!A/HU&PP3`STUKK2L.\:7..TA?ISHDP2,U*:17H[Z8:<B:$[>'`4
MPM>!,DG#2&G&>7I64$J*WF53V/F2U'M7)G3)>#5,:Z1X%B\#X:3H27<J[6^J
M1N@V&K(+1BL7E77'->,3]WX].-K2Q;UO!X4SPY7$O6\+Q+T'G2RV6@W!I&AM
MMDYGO.QP;'4I91SZ<A<R<>;6P9E*\"G)$<IE4:9)&2K-*BE6"P+4JF"MA/;M
M@>)#I`B-@HV\*(U[SH#"7SI7FC>G]P_J"473#U$,?Q4HG!BN)'/ZMD#F=!.B
M#3%`0*>MB]FG;+4_[BY;[][A/-T'8ND1!I22T_-UH'!BN-(L]UX?5.?KUOB#
M%)Y8"98@O7V.6/KUX"R6#G-ZD"X]*\$Y+%UCX@,1M*/`D\HB&LK/>=*^`>L_
M>T4+Q+59%:0=`^1B6%*B#M,S+"E."_E_CO8,@](F[C97B(6_8:XDI&\+9?SR
MII1F58QD+"!39N*5$RU8WN^S<6^0A3.C<&JXTBS2L;I4IASWA`K':T#A+'`E
M*?*_+2Q?[UV*_*\>A3$SH21S^K:PF'N7.?UZ4#@Q7$F6;-M"X6^!*\VR]/J@
M^H;QNB+E`22R,7L)%$X,5Y(>+ML"Z>&2=+*-YX1^&3$8DY5-IG&31[GWCG3P
M[B3KU2;L'T!$M=Y[+W+8TZFM;%;%-D$K7A7)9K[%?LR!=M?%;!P5!I7E3<3#
M?!_(";\UJ.PU"2:M3I`+K%R(1*RTA@[!AC01":GM3DL$O(T)I@S1M2HD&S@R
MB=5,H[-91.&_F2M)!\9MH;;H:B+JX+0RV!G'A0YV7A*%Y,BM'H5SQ95D1VY;
M.+H9GW1@W`X*)X8K25^V;>'H0$Z6;-L!;;L9C<7%26-)UOC8"-*^L)PLV63)
M-OD['BR_9).NRJO'X@UV9<FV
M?BPQI\N2[<I0&#$32A*];S-Z)SQPI3ES.O9#U8XV40:)S-\KP>+]T[O1X]($
MZ1.F+O[W_%B<=.F?OGXLX=[A.3*G7]^<7JGA2K/<.QHV=>;UV6+8:\`2I,-S
MQ-)OV-*G.,9I7MJKK0.+67J][``MNHBY&:@]I.@!"=BO5L0*NMVWQJX,^7`.
M4%U2:VK`6(UTL$BP&13W?6.KU(,BR96WP<%.D%$#,71Z-GKS>=F%_\5<:5[T
M#N_33KY-(H+\*&-B;;J=(6?>6'$))\42I,-S9$Z_OCE]J1TY!]>*-&&N7Z?+
MAMPZ4,;$3"G)CMRVL)BERX[<]6`Q2^_G]`C77ZT?A6?6B'M?"<J8F"FE67,Z
M7">VNCIS!^?BPOI:4!@Q$TJS2(>X>$`Z7DS6TI=M'2B<&*XT:T['2A1DT4:>
MS8V_GP,R2AR?%NJN"GH1*['`6W`TZ9]9IE=+-[\W&9:ZKMMRV8N@\(1+KHH"
M-MD4X[\`"B>&*QU#^M^Z!R4L&A(JPU""U'?%*5I1AJ&1^=`@H@"E1+J,RN%H
MJ[=F+X'BCZ^;12EHV0S!$
M!$7AG62PGAR%T\"5OM#.`YZ#HR?!_IN)U=(39-J:6`T6-M1-)`+8^P_5SA-8
ML`GD2<F`R%=1MIV61`='HO`WS)6.(;UW[WC*%DG4!@WZ#'7)>+:9R"0`AZ5&
M*DZ='(5SQ97FD$XLKY+N1G:=56_[0O#Y43@-7&F>I3-?CC7_3"0A&LS@1MIS
M70)'D_YYSNN<GKLYG81M&F;P(/NPZT#A7'&E.4NV!!<3C8O,O8=)_\[\00W2
MR(\2?[`@"B>&*\TC':(V[TC,W8\#X6X-*)P8KB26OBV<@'1NZ36@%^[6@,*Y
MXDJR.;,M%/[NN)*LT[>%HTF70&X[6,R]R^;,]:!P8KC2K*-5Z!9@Z#X[3.!)
M>C.M!(4SPY7$TK>%PEG@2K.V8>MA66482,]D'$"?H":PEYC[_"B<!:YT#.E_
MXP_ZEGE\L>I58`G2AW-Z=1EL4I^T=!D(9P>;TU][RB:6?CTHC)@)I5F6/A6U
M2?B^*AP=O;]AR08YK;+]MAHL8>GPG/ZR0V:67EF74'T-*)P8KC2+]/J@/G.F
M.UJ5]=DZL!CI$LA=#Y8/Y&0;=O58GG0HX64S.5IU<)&5&K^#^Z=!#MXN@,*)
MX4JSW'N"FV697ER#[MKT^AG<6Z,;]/5&VO@JF]Q,7AB%OV"N-,O2ZX/JU<0,
M`XKPZ5N*;90#EPN@(K]>@A>$U
M8.G[Z5*4X`I0.#%<:1[I[03N-6&E)9C<88":0BY1%>0R"I>GQQ)S>OL<">2N
M!TN33LN(?,N-7\A;`PHGABO)G+XM++9DDSG]>E!&Q$PJB7O?%@KGBBO-(AU<
M<JR%AFB5,2%]#2B<&*XT8W/&*NAA,5TT3O9F5H&CZ\A)\<#MH#!B)I3>2CKT
MS@D#C^^`=3(0++`>M`R$$V,)]]X^1P*YZX$$<C>(Q0(YF=.O!V<A7>;T=:%P
M8KC2C+QWFN0^43&R%T&Z%"E28E57I$1.W4^-PEG@2K,L'3)GC)]B4^QU%2B,
MJPFE6:1_UH:%]35@"4N'YXA[OQH4_LJYTJPE6WU01Z>!O`JC^]-6"W<==)1%
MW"6P!.E?FM.K50O#JX#,Z3>(Q=R[S.G7@\4".9G3KP<RI]\@9'/F!G&")=O^
M.3E5SD,[HV='ZI%`XFO6=))O$VZR(A_T"1JZY69$D@WYT`[/E,FV?7`@(E\1
MV[\G)<U$M*40Y.DFNM\/*?G);KB$0N$\<*571.]93_&YV==X72B,JPDEL?1M
MH?"7SI7>:ND]Q9M]C=>%)2Q]2#H82FWATIEZJNU9&A%8&+7^T&;>)\FI.CT*
M9X8K2;K4ME`X5UQI%NFQG8>326SF-&0*CS`+Z\A,7='INQTM44;+LBC\_7*E
M>>Z]?]"W`X\?$_7E_1`3-L^/PHB94'HSZ1D>;H3U56`)2V^?(W/Z]4#F]!N$
MS.DWB/.0+G/ZJE`X,5QIWIP.6Z>6D@XB;<>[,UD1+93(OMW)43A77&E6YDS/
MW7C^SF23+GIM<+O<D&D=LBU2S%.[XY)/LQ0*XVI"22Q]6UB>=#EE6ST*?TE<
M2=S[ME`X,UQ)2-\6RC0-0R4A?5LH_'USI3?OR&U_FKPJ%$X,5Y)`;ELXGO3/
MLPZDZ_U2#=XCOO]6`H\V@8B`.)VKR&'F#/F@C;!AE*H(NK/'KH)%(S+0",X3
MB8'RE\%RD28BEZ!FK7<WELE5^#OG2E\@O18//,#GT.&W=,*WN2@S]050&#$3
M2L>0WENZ`R?J*\-@^ETA]RJQQ/1A+SY9\C%H)31P$'5DWI)A+HXE++U]CKCW
MZT'A-'"E6>Y]@KS>BX@O7P46<^\RIU\/EI_3\4E>3U$\]N^#.;R;%V[)TUX$
MA1/#E?:D^V-)#[A0IU&:@^N1.25+PCD/PDS'`I0T4$K1X0!]8)4*=+H/O28=
M7OR14)PR)[DSVZ-:NO$QF9Q-9X(-`=%:W00\WXBE;POC0.YP$L6QT3M?H('M
M)R<7EE:"PIGA2K).WQ8*?^M<24C?%@KC84)ISI+-P1E&KE.Z@YS+K*G(=B)9
MLIT?A3/#E>98NL,#M#3%(XZ
MP!A34E/L$BB<&*YT-.FF63>[=AE@:^JK4CJ!R%<1)-@,19Y]4+4.P:KJ-K!5
MHY%E]QM0^/OE2F\E'2XPVIH@T8@R<.?(T(#Z5BD*PR=&X:^<*\TAW<).6:@M
ML7N1"T0$UA^LTU11P2E:,#X198CC@Q;NET'AQ'"EHZ/WYD$8O<>:,*5<P!N,
MF8@TB+R$[^='X<1PI;>2GF`1+ORN!(5SQ97FN/>.X9K*2,VZ%\%A2XQD:'B0
M2#Q_<A1.#%<2][XMG,#2X92MUIAH1&Z03$,]?A7`*,@UG'<1;KHGZC/@0K5<
M:W\3RIB%*:6C3]G,?E/&P#EW93C`(7FN5225S[!Q5^L4*`^C)=?^?(T(=HP"
M^2`>PNLZ7KP->)R;7:PSB%<1=^\]63:`HB-#:VJ0VD.#5&\B&[[P5\Z5YKCW
M*>YP.[[6'E(>JOSG0.CP&O,O`KD>TW^X6='+1+`0"B>&*\UQ[V!=`Q.NM'W+
MW<$&#.?J,"8]O95TW'51)'H/5G_&EPOK9\=B[KTC/0/#S9JL9QC/;5VM"-QK
MD=DZ0S==YV4<G!J%L\"5YLSI&>X>.$L8-BBJTWS6[1AS1G*@+X#"B>%*LRR]
M#(H_)USI1F6KO&$U,>>ST;44NQ#
M74_E##>*G.S-7@"%$\.59ECZ-.EXD4S28=>!PKGB2K-(Q_N$/DZ9=2^"W39O
M9!Q<`(43PY7FD&X2=NKHUV>-"':X:FRG#=:.L+*?>@$43@Q7FD.ZC;`[8ZM[
MM]'#D,HFVD#$L#M;^_8U(MAD-:Z*NHQ-(O*P<Z?(![$^84W.Z;12%F<R1N$O
MDBL)Z=M"X0QPI1D'+CK"H:FNIRLZPBTUG63;91THG!BN-,?2(^12ZUKIJ7FV
M8^,`4B9T/4EM1/C!&@Q$V,K3==&OH\$/BOV^'H43PY7FD)[@J,Q6ZB"RLX9*
M+(@T$6%.=":B#")Q$`NC,&8FE.:X]^S@2<2&<SN>;,V6:MP`L%ZSI72"$^O!
M8.E)9T/#$U$`$1]3B@P@J#ECJLM(<#!$^KSK!.?^QCHB,B`B3@J^T"CB?F"@
MZWPEP[/P=\>59EEZQC=N"9^8]TZH@O,=JSBAE*K*WE6\S&M!X:^<*\W8AC4*
MY@E?U^D&JT%Z:XD(-ND:TY-MV+.C[M*,.1%^EKVOQ'!IF_U
MFG085"V0R"W'A5'X.^=*LRP]:^"36'K*C/5H.I%8^ME1.#%<:9:E9\,9!H]O
MPQ3IS"&(79\:A;/`E>98.JX#0LV(,QJNHJ5$)'")*DL.Q250&#$32G,L76=X
M4NW+1BFN(DBS[P4&UD8A2Z!^>A1.#%>:L4XW=MQNT5@H.Q%K4G2S$H9[##69
MQF#=L>BK/[`&18:(X#J4(UHP7F--;F]$@8O@1SCRC0KN5]1"],;@90HJB6,)
M/.B:Z]X4_@:XTAQ+GWJ5,*"BE;2G=6!YTJ>L#$1>$XO5W(A[NY:A<5H43@Q7
M$O>^4?=>F>%*<Z+W*8JAX'L,A*E>(M'[^5$X,5QIEGO'VZ]Y3'",$Y37<1&9
MZ<-]=2\)58NC,!XFE*2SP[90^(OB2D+ZME#8JYM0FE,\<((#"[NP/D]Q<$LO
M>RTHG!FN)$7^MX5!D7^;@_%8CKDA+S5L>=LX5W'OVT)A7$TH2>.>;>'H'BY'
MDX[M.R=;=PC#J\`2[3RDA\N5X6C2)9#;#D@@%W3CE&V&RT!>16U<-%I%*X'<
MQK!\KU7IUK1Z%,;5A-(<TK%`G*U6YB(4ES+58;N`%QJ)%F\#4GM^?,M^I0R?
M-V`)TJ7![I5A"?<^6K+USKSZ][[_EK"^!BS6EZTG/>)"W8V=LI7;+"O!8GW9
MI!G?]4`"N1M$8>]\0DDZ,&X+BS?CDPZ,Z\?R'1BQ"C0Y<0DZPSZ?\D95'Q^,
MP0K@(9&MU``)KRH23<AN55*T9AD4_EZYTC%S>N?>24/-GK.`-!)F/39\I,RR
MT>)#>ZVR.H@^7I!)X2TH_)5SI7F6#M:;,Z'3@TA,=QU8PM+%O5\9RC0Q0R5Q
M[]M"X2QPI5F6/D%GY-VU8Z\EMGMV%$X,5Q)+WQ8*YXHKS=F<"<DP.FMO=B%K
M#2B<&*XTR[TG[LOKL[_E8TS<^]FQ!.GM<SK22:/[CN&<(E1D-LG[1,1]T_:Z
MNYY#1F$,Y$@^8\5'7_U'UB@B']8-6J&+F6@J`WO#QEF29Y4R%J<V3I$-1"Q=
M:<CI08+3`V/JWY2@<IHAQT$)9A^CB:A]5%_;=B^!9@J:I!!&CRG$VD5R&!%A
M::/5\DN6PK]B-ND#2R</ZLT:#M[V*Z[QNBR)I5\`A1/#E>:0#A[#6&X4Y"0U
M07UP(XT=+H+"F>%*XMZWZ=[)'R&DWPSI]>\2TF^&]/J+A?1;(9UP]0;2S>\5
MUIYTI#.Z@3_4N4A$%IN[NJ%8J?;-N?VMZ5ZLX<<Y2T78N+.V=-5PT<G61B)*
M=S_'NEB[`RH%C4#MK>;:%?X>N-*<!KO(FB6O&"J`6B5Y[RM!X<QPI3D-=LGH
MZ5G7.`X\&0CCOAP*>T`./EA_U+?<(]VDD2Z"PHGA2F\EW:8!=ZT()N1:*UKU
M$WP4AD^,)=Q[^QP)Y"20DT!NQ5@^D$-#S6G*<4LDMP843@Q7DD!N6UC,TB60
MNQX43@Q7DCE]6RB<*ZXTQ]*;>+9]4*PV;+0#D26B_NMN\K5?%H43PY7$TK>%
MPHGA2K,L'=:<KC;D:D3`KR<BJ!(U%`&-M8\#_5$W2<ZI4#@Q7&D>Z6"JM5EZ
M8VW`7:+N';XN1F'X_%C"TMOGB'N_'BQ.NHWM@P(A"`N)!)V)*(&H#@WK/,05
M03E%-+LNWS[FX(D8:??1TJ]2<.W-!QNKLLF0`>A]('M&)@7L->HR&3LF)HOM
M?S-99!J?H9^[UX.'5,=V/>.G\!_/E61.WQ9.$,C)G+YV%$X,5Q+WODWW3HCA
M2G,.7"Q<6`J.$`015G!REVT=*)P8KC3'O7</(E,S>785P2%,L$Y3105S?3`^
MA2E/<3W6M&8L07K['''OUS,@"^>**\VR=*CG7ULI-A*P7ANXR!)1]_W7\_*N
M%84SPY7$TC=JZ94%KC3+TK.!.9W8<,9YNHJRAF^+=#[/.#:"GAH<U_-.5X_"
MF>%*(/.]`D1N?@]#:06,]I#VO.
M$!T97`Y]!SG4Q7XEP=_P,"K\77"E.:1W=>14?<\!NO%DLE_C,U033=4S^]2R
MEFL/[D8$92S)T/#8[4?7,>!MP#8"V1&?[E7$.M*>+!M`T9%!!5^;B-/!-D.)
M)/\XR&M-^IJ\^$$4_E=QI3GK="P(',F\UUEZRD0$1IVD[O\%4#@+7&G.G$Y&
MSP3#U9=;F`3(T``W+E5H3H\E2&^?(W/Z]:!PKKB2S.E;G=/[OYTKO75.QS<F
MT_=*,`[D)GF9-Z=/6(X[9#E$`*X]$QN$(I8QT>B@]T<;,+B+H7!BN)*X]VVZ
M=\(55YKCWJ>XP[8N)+;S6.:59-)YK[$W;^A;K9,/)R>SPU(H]=W:YF5'CR^^
M^5=LED\I[B?G.>X=K&M@PI6V;_D0VX#A7!T*9X8KB7O?J'NOQ'"E.98^P3#R
M2T>![T0;>(77AS(F9DII3[H_EG2'7=BH,X<I@YRC=D-#3L\O@9YTJW3C='43
M0P%!WNC4S.Q*._/-6TF'>\G9$`D(Q-(O`D*Z40W5&;8XLS&YD21E]OE3,J=O
M=D[7SL;D(2&]L7'CC+<I-,Q_*7IOG].3'K"S4GW]?>^.2$10=)K<70JN'1K*
M9>(0H+<72;3JFGYLX^U?"(6_3*XDZ_1MH7"NN-*LZ+V.GFJP^C.^7`SV["B<
M&*XD[GU;*/S]<J59ECY!%&?387<?N;YP"11&S(226/JV4#A77$E(WQ8*9X$K
MS2$]6:SR4.E,6,4U!R)J)61D1.SXXQ(1@:0*8G!8N-61A\60865MC"<#*P8/
MF?3&*$.U#1::U5Z1[\?RM>H&9IS"_V:N-&=.)P_JWZ<UD/R@4R9!?;0@(S09
M%,E.W4E1IHD9*KV5=!^PW'+CL(D4OHY8ML-?('DQI\42EMX^1]S[]4#<^PWB
M+*2+>U\7RB0Q(R5Q[]M"X5QQI3F6GBQ4<C>$=`-EVTD2!?FZS;_B]:%P8KC2
M6TF'D@!6+IFO!(5SQ97$TK>%)4AOGR-S^O6@,!8FE.:0GH$J3_(@(#6*TI2[
MPJ$UF,_81LL-])2&"AE..T=&$3Z1<`;G\]*/_2B4\4N;4IKEWKL']70HS9Q[
M/\*$HDN@<&JXTMM(AV.W(>F]OQ?6+X`E++U]CLSIUX/"B>%*,J=O"S*GWR#.
M0+K,Z6M#X=1P)7'OVT+A[Y$KS;'T"8:A:)0C-8*Q5JLS]:`U8Y<!$Z>X%2J7
MQ/*D3Q@Q[/:YD)FIDUMJN>OA(O<?3HW"7SE7$O>^+11.`U>:<Y<M=WW9_)19
MRW6T-6!,>GAK)0JH_"U^>\U8PKW+G'YE*)P8KB1S^K90&#$32K/F=`O^W1*S
M-BB*4PLTF>;/CL)9X$JSW#M<-J,-=F6]O3+(YLP-HG!FN)+,Z=M"X5QQI5F6
M#J_?DP(S.6';+#*GUZ\3ELZ.PHGA2C-(UPH".>\)PW"-PI/\""']DEC:TK4R
MV%VM(U@K#;WM$AT&T-=.RH]<!(73P)5F+-FT4NC>">L*6*<[L]7X9<EV=A3.
M%5>:9^G@WG.LI!OEX>E9U_9,C0?`<287'LZ,,DW,4&E&]*Z5PTZYA%V'[5<M
M$4%S3B*!!J>D$R>9*610+(K"7O"$TJSHO>M[JV4&7RL6F],ED+L>%,X,5Y+-
MF6UAL26;1._7@\)9X$JR([<M++\Y(SMRJ\?1EOZ9=A[M<SK2M8(ZGJ:NQC3<
M<5&F.ORDP>4K%>OA6_=1159M4)8J9[(`#-@G@GP.VSTD\@U84#Z29\%PS)X\
M"_M8>#L..[,E(S1AAQ*R(('>A9E*6H&ZAE'<!W+1^&!,TAZ;$T<5&VIBPT">
MT\.E(0X*P2KR'K%X?Z8B>-O93#&W_M=VW:BDVVA40P;T;0HQV>QT"%G/:^<A
MFS-7@,*YXDIS2+?0&3T39V[A%G`B/MH"Q:DVS]46$B-3C0"UA88RJ6;A:`M3
M0*HK@484050_:!*V[*F/QQ5A[4?C,1-
MY9!!K?F?9-Z!?L"#B<U"9Z/&G`*QBX@MX<\RP`O_5JXT*Y"K#ZJ^W$"F3`B^
M%O;>BU%(1*K3U"D0SY]@;@\^#3Q(/U#%%<Q!F29FJ/16TINAKN'9CC`9443G
M?K#C/>5.N#T9CK9TB=XW&;TWMAZ3!Y<;M;,YJ;!_!]_,:;LIT?L5@$;OJ>%:
M.?"ZT46K[NE`FB1DIB7O?IGLG+X`K
MS3E/-Q"]I]I+K1$!G3;+X?DJ4#@Q7&F.>S<)+<I,D3YA9.*RSXXE2&^?(^[]
M"MU[?2=<:9ZEP_LFF9$&MJ^2]U,4B*6?'843PY7$TK=IZ>25<R4A?:.D5Q:X
MTASW;C5G16?&7?TZ<>]G1^'$<"6Q](U:>N6**[V5=/B+LECU2E`8,1-*<TB/
M'MMI5E.,["=$#P_4SGHBU2"LUAWP
MMQ"!ADU\E1/5@]HKBAST>KA$H\@B9+_O#WK>Q/J]WN<,XF:\UR-"#SY#D5-#
M!WG?Q.$Y<%+9$@O)<%)OB,/#\_S%S&@)TH=S>O^@^@OA-]?NJ[T229<@'D+\
MP8E1.#-<:1[I,)U2UG'CAUQ9MS##"L470>'$<"4)Y#8:R%5BN-*<`Q=KD70]
M)CTK+P<NJT#AQ'"E6:1CM$(2(VW$V$1(7P<*)X8KO6).SY9&<AYNRF43R8DK
M^<HJLBQTQ7Q8[:8\!PL#T]2D(F'#$&6:F*&2+-FVN60C7\^5YECZY-\1F<?O
M4LE)0`^A9-9R\'9J%$X,5YI#.D3$6A%[A81VK2VU.-"23;I+H'!FN)*X]VVZ
M=_)WSR9]:.G1PX/J*X7;+"H1D4^PU&V$9+6+)-'/UI\E+F$Q+$^Z"]R9.XBD
M]3ZV/V3'0NK94#A77$G<^T;=^_#]SB+]BY9N.S;$FE>!)2Q=W/N5H4P3,U02
M][Y1]SY\';-('UJZ1TI45IZ&\!8C\^8EB55?%F6:JZ'2$J0/!Y6P?DDL07K[
M'''O5^C>EUNGZP3!@?+D9$QV658$V9&[013.#%=Z(^D#;RS<71Z%<36A)'/Z
M1N?TP8N<1[JX]RN#6/H-6SIAX8VD!WCW).^]XRA%,==5H'"NN-*<;%C"<"7=
M=[BM*/##U8O%BT,H-J_24>#'Y0<
MU]=C"=+;Y\B<?HUS>D_,VTC/\"!+2((_PY)AD.%6DR7#(*667O+G)\B@M^2U
M);B;9+4GH@`B^D%X.ED%)"@S2P94@N()AI2PQ!6%(=>(
M%8]UOI*@I?#?S97FN??^0?4U@1<AE;DC&)PFMH\GNXG.`?U`O(IW>34HG!BN
M)):^34LG;Y@KS8G>$P1RUE`2.HD$[ZM`8<1,*,UQ[PE&O9WB?&R*1G,;SE.6
M?A7V[9XM_7@,*)X4JSW'O&T6.)$8/'
M)U>+$[:^5MR*J7W6D7@5%G0M*)P8KC2'].S&O<T;4>LC'=D.R7"#T4FZW"50
M.#%(%<EB6
MX3K\0"23P+FPA*6WST'2#;9;]-5'&FRW6'M;&NC7[>M^C5&J#>=)-Z<<(CB#
M1(9*/Z!D7+P!A;]BKB1SNLSID\\12[\>%/X^N9(LV;:%Y:-W">16C\*)X4KB
MWK>%PFB84)IQX&(4)-MY1PB%E#9O">M`GV\B*SF#.3L*9X$KS7#OS>CQ0#HW
M=$]$%D1Z:AAP?R!VO2@*9X8KB7O?%ACI;W;OD`_L+2$44G@'IAY-)Q+W?G84
MS@)7FN7>L^$,PS1OPQ3IW!^(%9\8A1/#E>:1#MP%2CI8>MW\:A@&?^#DP.4"
M*)P8KC1G3C<:^IO4(S5C%'8MJ:3KG$'DB:B5U.1XHZ'_:XA$!#NLP1,13/3!
MIBIR\$%=78NV"43D@U#O*BCRL\#_9**D80PG\BCH+..OMWMDX7\)5Q+2-TIZ
M?9M<:8Y[AW.,X/,445?ZDK:&)4AOGR.6?CTH_-5Q)2%]HZ0OYMZQK9P7][Y:
MB'N_84LGQ'"E.3MR>$$J),?H)*Q`,DW(43;D+H#":>!*L]S[E`WWSZZB=FC$
M*6]PI>9S15B"]/8YXMZO!X6_8*XTAW3;OJ28ZI&:]>VKC*':M74)1'4.L!8Z
M$/O*G34H,D34DAX=T8+1$NL!72,*7`0_PI%O5!I$]:<:*)`1J22.)?"@:^X9
M6-B?,J$TQ[W7!_5O"=]WS9IK;#^.';Z!'MDATU@`/$2:LOVK?>,K0.',<"6Q
M]&U:.GD#7&E.]#[Q*CL.O!0/7`>6(+U]CECZ]:#P%\R5Q-*WA<*)X4IS`KE)
M*^N?72U6<R/NA]W5FM"58`G2V^>(>[\>%/[JN-(L]SY!L0<.R-K+]A)Q^.='
M82Q,*,UR[V`99/<-'QWC!.5U7$1F^A[,7&XY+8["F)E0FD=Z:^E)$9\<8`^T
M&0G$WT)J9%)ZS/Q>)#R?$F6*F+'2G#D]8C7K6AR[F2@MB.HX"%!$.X<Z"F#R
MS($HP:YZK@6U38!@()-I/L!XS60"#U`4/I,$ZZ#A\88\"W]IK5MI//Y2LFD/
M=_PR.4KP\(6IEO`VSL)()P&)@QW&Y.IOL`D^2'Z#A23D,S>E+/S;N9*0ODW2
MR5_"E83TC9+>_VT32D+Z-DDGKXXKS0GDICAP2%Z5!`,2"(;Y\CEBZ6
M/K3T(':])HBEW[*E5V*XDI"^3=()5UQIEGN'2NX#\C**ZM8L^3KQ^&='X<1P
MI3FDP]#-M0&CB7!8EE,0@M>!PIGA2K-(KP_J68>,9&%]+5B<]`2+<F7J]):@
ML:HBA:,2',8I(V<K%T#AQ'"E.8%<[MJ15H)S&](H4ED.FX<H<D$A1121D0&%
MQY257)IE4?@+YDJS++T^J"?/.X\M:!5):T_.&?0*-(I/V)F6N@J#SQ2_L`C*
M-#%#);'T;:%P&KC2'$O/VD&A4$6R8+)6^/R@:^\NDQ6PZLD`@;F>I+*17R;4
M+X,R3<M0:1[IX:"I"Y'KP!*6WCY'W/OU0-S[#>($I(M[7SL*(V9":4]Z/M*]
M!^"3GJWT76VJ*(-(EF`70>'4<*59I$.-"4VJ!P;PV3K0@[=V+TB3@0`'7+70
MMPR-DZ&P=SZA]`721Z=LW+`AN-NSQRD6/L^/PHGA2L=8^M>'W3MT.]/$SD'%
M2&VIRZ!P:KC2*RR=]*JK(CLU$L34SX["B>%*\P(Y;&,8&,.DPT?S=9#*8HPC
MZ28A*Q-Q-'@V/QA2R"9`-2R=,YLRI,?7EU#X>^5*LRQ]DB"+0RHJ2E(>\Q8[
MUFJ&#=8ZT\F28F-1X>58';VG8M"-5WR-^!PHT\0,E<32MX5Q]'ZP`^.QI$>X
MZJ^#929-$R.[KYL0"6>GQN*DRSI]_2B<*ZXDEKXM%,X55YH3R$6H':.)$4=(
MQ=*:1&S00%T;J?][`11.#%>:9>D)3L[(.CU"-7"E252.)[!F(#)P/&=(S\Z8
M#)S?D)3JV!W8$1%\:9`=OF-0^&OC2O-(A[PWLC:+&9,NR>(JXUV5)EHGET>Z
MX>$]8YU(=)KH$E5"TME09
M/JVO?OX9DQX/'JT>YGR8&`F6;EQU[_AB3:"B=F@84JHK0Y\G0ZC,D"C=_+AK
M?\WK0N%<<:5YI+=F2%TT>;9PMP:<A72(RTV0&R[K0.%<<:4]Z?ZX.5UKA7-U
M[[@;$49MO40EC9E2BI2.ZSZJ8I5`"(M^`UULC>9;%
M\A?D609OSM[LQ
MSFB;0-QIVP3)7R"=6GI#'*1+*?(>X2B57&K4V$(Y9S/%W/I?VW6C5).*#=$>
M&'?6V2:R;0RL-7RQ],U:NO'-0B7`6CDE%[2-^P8[S0L12]\6B*7G9I6<$U1_
M:$C7(:C8K.0:(YM!.A:4,&3G)$0X(PMRX+D2%,X,5YI'.BX#R,D)=.(TY+PE
MPM"0VNX70>$T<*5YI(?QMDN(L!-#;C\(ZY?$"4CO'U09]A"B[6OT4`?0303"
M^WFQ/.FPT4ZW80/$=L9EL?15X&C2CT^7TGQ.%X97A>-(_[I9NM^]//_ZX9NO
MOOIO__T/?_Z?__'N+W_XTQ^^^^O=O[_[^\OSSW<?GW^[__F7NU]_O'^YOWO:
M_7S_?_R[#S_N7IZ?_MU_^FK_S^:+=C_<E\?G=[N/#\]/9??T]&GW^&'W^-7O
M6OP'_/_^'X"OX"'ESOCRM?;?ZN;7E?TOTD8I]=77>O^CFM_TOPD$`H%`(!`(
1!`*!0""X!OS_UHT<I0`H"@#?
`
end

Bye,
- --
# $Id: .signature,v 1.14 1996/08/08 19:36:32 piero Exp $
Piero Serini Via Panzeri, 15
<Piero@ESI.IT> I 20123 Milano - ITALY

From scrappy
Date: Sat, 29 Nov 1997 21:08:10 +0000 (GMT)
From: "R. Hague" <rhague@erienet.net>
Subject: [none]

- The version of PostgreSQL (v6.2.1, 6.1.1, beta 970703, etc.).
- Your operating system (i.e. RedHat v4.0 Linux v2.0.26).
slakware linux
- Your hardware (SPARC, i486, etc.).
pentium 120
amdk5166
- Did you compile, install and run the regression tests cleanly?
yes on pentium
no on k5166 (minor floating point diffs)

If not, what source code did you change (i.e. patches you
applied, changes you made, etc.), what tests failed, etc.
It is normal to get many warning when you compile. You do
not need to report these.


Richard Hague

rhague@erienet.net (regardless of header)

From scrappy
Date: Sun, 30 Nov 1997 22:36:03 +0100
From: Tamas Laufer <lt660@ipisun.jpte.hu>
Subject: Bugfix for FETCH from BYNARY CURSORs

- -----Bug Description
Declaring a binary cursor in a libpq frontend application and FETCH-ing
from it results ASCII numerical fields instead of binary ones.
E.g. see the supplied example application testlibpq3.sql + tetslibpq3.c.

- -----Platform
Probably on any platform, but observed only on an SCO 3.2v5.0.2

- -----Fix (Tested but not too extensively)
Comment out the line 151 in ./src/backend/commands/command.c containing
queryDesc.dest=dest;
in function PerformPortalFetch(...);

- ----Explanation
I ignore the very long "proof" containing the path from parsing to the
selection and application of the appropriate printtuple version
responsible for correct data format.
I state only: the data format is uniquely associated with the
destination of data. The correctly established destination for a binary
cursor and for FETCHes referring to it is RemoteInternal, but this will
be overwritten to Local by ./src/backend/commands/command.c :
PerformPortalFetch(...) in line 151. This wired-in Local destination
value is propagated from be-pqexec.c:PQexec(...) (line 150).


Best regards,
Tamas

_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

From scrappy
Date: Sun, 30 Nov 1997 19:45:00 -2900 (EST)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] Bugfix for FETCH from BYNARY CURSORs

There is a patches directory on the ftp server for 6.2.1 that fixes
this.
-----Bug Description
Declaring a binary cursor in a libpq frontend application and FETCH-ing
from it results ASCII numerical fields instead of binary ones.
E.g. see the supplied example application testlibpq3.sql + tetslibpq3.c.

-----Platform
Probably on any platform, but observed only on an SCO 3.2v5.0.2

-----Fix (Tested but not too extensively)
Comment out the line 151 in ./src/backend/commands/command.c containing
queryDesc.dest=dest;
in function PerformPortalFetch(...);

----Explanation
I ignore the very long "proof" containing the path from parsing to the
selection and application of the appropriate printtuple version
responsible for correct data format.
I state only: the data format is uniquely associated with the
destination of data. The correctly established destination for a binary
cursor and for FETCHes referring to it is RemoteInternal, but this will
be overwritten to Local by ./src/backend/commands/command.c :
PerformPortalFetch(...) in line 151. This wired-in Local destination
value is propagated from be-pqexec.c:PQexec(...) (line 150).


Best regards,
Tamas

_________________________________________
Tamas Laufer
Voice/Fax: +36-72-447-570
Email: lt660@ipisun.jpte.hu
H-7632 Pecs, Fulep L. u 26 III/11 Hungary

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

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedOct 31, '97 at 11:25p
activeOct 31, '97 at 11:25p
posts1
users1
websitepostgresql.org
irc#postgresql

1 user in discussion

Carlos Amengual: 1 post

People

Translate

site design / logo © 2022 Grokbase