mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-11-27 07:21:09 +08:00
Update faq and hpux faq.
This commit is contained in:
Bruce Momjian
parent
e7253d893c
commit
3fd4755ee3
92
doc/FAQ
92
doc/FAQ
@ -1,7 +1,7 @@
|
||||
|
||||
Frequently Asked Questions (FAQ) for PostgreSQL
|
||||
|
||||
Last updated: Fri Jun 4 23:30:19 EDT 1999
|
||||
Last updated: Sat Jun 5 14:22:43 EDT 1999
|
||||
|
||||
Current maintainer: Bruce Momjian (maillist@candle.pha.pa.us)
|
||||
|
||||
@ -13,6 +13,9 @@
|
||||
|
||||
Irix-specific questions are answered in
|
||||
http://postgreSQL.org/docs/faq-irix.html.
|
||||
|
||||
HPUX-specific questions are answered in
|
||||
http://postgreSQL.org/docs/faq-hpux.shtml.
|
||||
_________________________________________________________________
|
||||
|
||||
General questions
|
||||
@ -141,13 +144,13 @@ Section 1: General Questions
|
||||
1.2) What does PostgreSQL run on?
|
||||
|
||||
The authors have compiled and tested PostgreSQL on the following
|
||||
platforms(some of these compiles require gcc 2.7.0):
|
||||
platforms (some of these compiles require gcc):
|
||||
* aix - IBM on AIX 3.2.5 or 4.x
|
||||
* alpha - DEC Alpha AXP on Digital Unix 2.0, 3.2, 4.0
|
||||
* BSD44_derived - OSs derived from 4.4-lite BSD (NetBSD, FreeBSD)
|
||||
* bsdi - BSD/OS 2.x, 3.x, 4.x
|
||||
* dgux - DG/UX 5.4R4.11
|
||||
* hpux - HP PA-RISC on HP-UX 9.0, 10
|
||||
* hpux - HP PA-RISC on HP-UX 9.*, 10.*
|
||||
* i386_solaris - i386 Solaris
|
||||
* irix5 - SGI MIPS on IRIX 5.3
|
||||
* linux - Intel x86 on Linux 2.0 and Linux ELF SPARC on Linux ELF
|
||||
@ -203,9 +206,9 @@ Section 1: General Questions
|
||||
California, Berkeley. It is maintained through volunteer effort.
|
||||
|
||||
The main mailing list is: pgsql-general@postgreSQL.org. It is
|
||||
available for discussion of matters pertaining to PostgreSQL, For info
|
||||
on how to subscribe, send a mail with the lines in the body (not the
|
||||
subject line)
|
||||
available for discussion of matters pertaining to PostgreSQL. To
|
||||
subscribe, send a mail with the lines in the body (not the subject
|
||||
line)
|
||||
|
||||
subscribe
|
||||
end
|
||||
@ -221,9 +224,13 @@ Section 1: General Questions
|
||||
Digests are sent out to members of this list whenever the main list
|
||||
has received around 30k of messages.
|
||||
|
||||
The bugs mailing list available. To subscribe to this list, send email
|
||||
to bugs-request@postgreSQL.org with a BODY of:
|
||||
The bugs mailing list is available. To subscribe to this list, send
|
||||
email to bugs-request@postgreSQL.org with a BODY of:
|
||||
|
||||
|
||||
subscribe
|
||||
end
|
||||
|
||||
There is also a developers discussion mailing list available. To
|
||||
subscribe to this list, send email to hackers-request@postgreSQL.org
|
||||
with a BODY of:
|
||||
@ -237,7 +244,7 @@ Section 1: General Questions
|
||||
|
||||
http://postgreSQL.org
|
||||
|
||||
There also an IRC channel on EFNet, channel #PostgreSQL. I use the
|
||||
There is also an IRC channel on EFNet, channel #PostgreSQL. I use the
|
||||
unix command irc -c '#PostgreSQL' "$USER" irc.phoenix.net
|
||||
|
||||
1.6) Latest release of PostgreSQL
|
||||
@ -368,8 +375,10 @@ Section 2: Installation Questions
|
||||
|
||||
2.4) How do I install PostgreSQL somewhere other than /usr/local/pgsql?
|
||||
|
||||
You need to edit Makefile.global and change POSTGRESDIR accordingly,
|
||||
or create a Makefile.custom and define POSTGRESDIR there.
|
||||
The simplest way is to specify the --prefix option when running
|
||||
configure. If you forgot to do that, you can edit Makefile.global and
|
||||
change POSTGRESDIR accordingly, or create a Makefile.custom and define
|
||||
POSTGRESDIR there.
|
||||
|
||||
2.5) When I run postmaster, I get a Bad System Call core dumped message.
|
||||
|
||||
@ -394,13 +403,13 @@ Section 2: Installation Questions
|
||||
2.8) How do I prevent other hosts from accessing my PostgreSQL database?
|
||||
|
||||
By default, PostgreSQL only allows connections from the local machine
|
||||
using unix domain sockets. You must add the -i flag to the postmaster,
|
||||
and enable host-based authentication by modifying the file
|
||||
$PGDATA/pg_hba accordingly.
|
||||
using unix domain sockets. Other machines will not be able to connect
|
||||
unless you add the -i flag to the postmaster, and enable host-based
|
||||
authentication by modifying the file $PGDATA/pg_hba.conf accordingly.
|
||||
|
||||
2.9) I can't access the database as the root user.
|
||||
|
||||
You should not create database users with user id 0(root). They will
|
||||
You should not create database users with user id 0 (root). They will
|
||||
be unable to access the database. This is a security precaution
|
||||
because of the ability of any user to dynamically link object modules
|
||||
into the database engine.
|
||||
@ -430,12 +439,15 @@ Section 2: Installation Questions
|
||||
|
||||
You can also use the postmaster -B option to increase the number of
|
||||
shared memory buffers used by the backend processes. If you make this
|
||||
parameter too high, the backends will not start or crash unexpectedly.
|
||||
Each buffer is 8K and the default is 64 buffers.
|
||||
parameter too high, the postmaster may not start up because you've
|
||||
exceeded your kernel's limit on shared memory space. Each buffer is 8K
|
||||
and the default is 64 buffers.
|
||||
|
||||
You can also use the postgres -S option to increase the maximum amount
|
||||
of memory used by each backend process for temporary sorts. Each
|
||||
buffer is 1K and the default is 512 buffers.
|
||||
You can also use the backend -S option to increase the maximum amount
|
||||
of memory used by each backend process for temporary sorts. The -S
|
||||
value is measured in kilobytes, and the default is 512 (ie, 512K). It
|
||||
is unwise to make this value too large, or you may run out of memory
|
||||
when a query invokes several concurrent sorts.
|
||||
|
||||
You can also use the cluster command to group data in base tables to
|
||||
match an index. See the cluster(l) manual page for more details.
|
||||
@ -445,7 +457,7 @@ Section 2: Installation Questions
|
||||
PostgreSQL has several features that report status information that
|
||||
can be valuable for debugging purposes.
|
||||
|
||||
First, by running configure with the -enable-cassert option, many
|
||||
First, by running configure with the --enable-cassert option, many
|
||||
assert()'s monitor the progress of the backend and halt the program
|
||||
when something unexpected occurs.
|
||||
|
||||
@ -461,7 +473,7 @@ Section 2: Installation Questions
|
||||
encountered by the server. Postmaster has a -d option that allows even
|
||||
more detailed information to be reported. The -d option takes a number
|
||||
that specifies the debug level. Be warned that high debug level values
|
||||
generates large log files.
|
||||
generate large log files.
|
||||
|
||||
You can actually run the postgres backend from the command line, and
|
||||
type your SQL statement directly. This is recommended only for
|
||||
@ -473,8 +485,8 @@ Section 2: Installation Questions
|
||||
operating system can attach to a running backend directly to diagnose
|
||||
problems.
|
||||
|
||||
The postgres program has a -s, -A, -t options that can be very useful
|
||||
for debugging and performance measurements.
|
||||
The postgres program has -s, -A, and -t options that can be very
|
||||
useful for debugging and performance measurements.
|
||||
|
||||
You can also compile with profiling to see what functions are taking
|
||||
execution time. The backend profile files will be deposited in the
|
||||
@ -684,21 +696,24 @@ BYTEA bytea variable-length array of bytes
|
||||
you need to use pgdump's -o option or copy with oids option to
|
||||
preserve the oids.
|
||||
|
||||
3.14) What are the pg_psort.XXX files in my database directory?
|
||||
3.14) What are the pg_tempNNN.NN files in my database directory?
|
||||
|
||||
They are temporary sort files generated by the query executor. For
|
||||
example, if a sort needs to be done to satisfy an order by, some temp
|
||||
files are generated as a result of the sort.
|
||||
They are temporary files generated by the query executor. For example,
|
||||
if a sort needs to be done to satisfy an order by, and the sort
|
||||
requires more space than the backend's -S parameter allows, then temp
|
||||
files are created to hold the extra data.
|
||||
|
||||
If you have no transactions or sorts running at the time, it is safe
|
||||
to delete the pg_psort.XXX files.
|
||||
The temp files should go away automatically, but might not if a
|
||||
backend crashes during a sort. If you have no transactions running at
|
||||
the time, it is safe to delete the pg_tempNNN.NN files.
|
||||
|
||||
3.15) Why can't I connect to my database from another machine?
|
||||
|
||||
The default configuration allows only unix domain socket connections
|
||||
from the local machine. To enable TCP/IP connections, use the
|
||||
postmaster -i option You need to add a host entry to the file
|
||||
pgsql/data/pg_hba. See the pg_hba.conf manual page.
|
||||
from the local machine. To enable TCP/IP connections, make sure the
|
||||
postmaster has been started with the -i option, and add an appropriate
|
||||
host entry to the file pgsql/data/pg_hba.conf. See the pg_hba.conf
|
||||
manual page.
|
||||
|
||||
3.16) How do I find out what indices or operations are defined in the
|
||||
database?
|
||||
@ -776,7 +791,7 @@ BYTEA bytea variable-length array of bytes
|
||||
|
||||
See the fetch manual page.
|
||||
|
||||
This only prevents all row results from being transfered to the
|
||||
This only prevents all row results from being transferred to the
|
||||
client. The entire query must be evaluated, even if you only want just
|
||||
the first few rows. Consider a query that has an order by. There is no
|
||||
way to return any rows until the entire query is evaluated and sorted.
|
||||
@ -811,8 +826,11 @@ being indexed, so they can be large also.
|
||||
|
||||
3.23) How do I get a list of tables, or other things I can see in psql?
|
||||
|
||||
See the file pgsql/src/bin/psql/psql.c. It contains SQL commands that
|
||||
generate the output for psql's backslash commands.
|
||||
You can read the source code for psql, file pgsql/src/bin/psql/psql.c.
|
||||
It contains SQL commands that generate the output for psql's backslash
|
||||
commands. Beginning in Postgres 6.5, you can also start psql with the
|
||||
-E option so that it will print out the queries it uses to execute the
|
||||
commands you give.
|
||||
|
||||
3.24) Why do I get the error "FATAL: palloc failure: memory exhausted?"
|
||||
|
||||
@ -826,7 +844,7 @@ being indexed, so they can be large also.
|
||||
Depending on your shell, only one of these may succeed, but it will
|
||||
set your process data segment limit much higher and perhaps allow the
|
||||
query to complete. This command applies to the current process, and
|
||||
all subprocesses created after the command is run. If are having a
|
||||
all subprocesses created after the command is run. If you are having a
|
||||
problem with the SQL client because the backend is returning too much
|
||||
data, try it before starting the client.
|
||||
|
||||
|
||||
132
doc/FAQ_HPUX
132
doc/FAQ_HPUX
@ -1,40 +1,37 @@
|
||||
|
||||
<PRE>
|
||||
=======================================================
|
||||
Frequently Asked Questions (FAQ) for PostgreSQL V6.4
|
||||
Frequently Asked Questions (FAQ) for PostgreSQL V6.5
|
||||
HP-UX Specific
|
||||
TO BE READ IN CONJUNCTION WITH THE NORMAL FAQ
|
||||
=======================================================
|
||||
last updated: Sat Nov 28 16:21:25 EST 1998
|
||||
last updated: Sun May 23 19:48:07 EDT 1999
|
||||
|
||||
current maintainer: Tom Lane (tgl@sss.pgh.pa.us)
|
||||
original author: Tom Lane (tgl@sss.pgh.pa.us)
|
||||
|
||||
|
||||
Questions covered here:
|
||||
1.1) What do I need to install PostgreSQL on HP-UX?
|
||||
1.2) Anything special about the build/install procedure?
|
||||
1.3) yacc dies trying to process src/backend/parser/gram.y.
|
||||
1.4) Linking the main postgres executable fails, complaining that
|
||||
there's no "alloca" function.
|
||||
1.5) OK, it seemed to build and install, but the regression test fails.
|
||||
1.1) What do I need to install PostgreSQL on HP-UX?
|
||||
1.2) Anything special about the build/install procedure?
|
||||
1.3) yacc dies trying to process src/backend/parser/gram.y.
|
||||
1.4) Linking the main postgres executable fails, complaining that
|
||||
there's no "alloca" function.
|
||||
1.5) OK, it seemed to build and install, but the regression test fails.
|
||||
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Section 1: Installing PostgreSQL
|
||||
----------------------------------------------------------------------
|
||||
|
||||
1.1) What do I need to install PostgreSQL on HP-UX?
|
||||
1.1) What do I need to install PostgreSQL on HP-UX?
|
||||
|
||||
PostgreSQL 6.4 is known to build and pass regression test on HPUX 9.03,
|
||||
PostgreSQL 6.5 is known to build and pass regression test on HPUX 9.03,
|
||||
9.05, and 10.20, given appropriate system patch levels and build tools.
|
||||
It should work on other HPUX 9.* and 10.* releases for Series 700/800
|
||||
machines, too. (No one has reported trying it with HPUX 11 yet.)
|
||||
Since this is a new FAQ, I don't yet have a lot of information about the
|
||||
exact prerequisites, but I'd appreciate hearing from anyone who fails to
|
||||
build a working copy, so that we can add more info about exactly what is
|
||||
needed.
|
||||
machines, too. I have heard nonspecific reports of problems on HPUX 11;
|
||||
more info and/or patches would be appreciated!
|
||||
|
||||
Aside from PostgreSQL 6.4 or later sources, you will need GNU make
|
||||
Aside from the PostgreSQL source distribution, you will need GNU make
|
||||
(HP's make will not do), and either GNU gcc or HP's full ANSI C compiler.
|
||||
You must also get flex (GNU lex) 2.5.4 or later --- all versions of
|
||||
HP's lex fail on the Postgres lexer files.
|
||||
@ -43,9 +40,12 @@ I'd also recommend making sure you are fairly up-to-date on HP patches,
|
||||
particularly if you are using HPUX 9. At a minimum, if you are on HPUX 9,
|
||||
you *must* have PHSS_4630 (libm update) or a successor patch; otherwise
|
||||
Postgres' date/time functions will misbehave. On general principles you
|
||||
should be current on libc and ld/dld patches, as well as compiler
|
||||
patches if you are using HP's C compiler (but I don't currently know of
|
||||
any specific failures due to not having recent patches for these files).
|
||||
should be current on libc and ld/dld patches, as well as compiler patches
|
||||
if you are using HP's C compiler. (The only other presently known failure
|
||||
from out-of-date system libraries is that on HPUX 10.10, the backend will
|
||||
crash after the second error message in a session unless you have upgraded
|
||||
libc to PHCO_16722 or later.)
|
||||
|
||||
See HP's support websites, such as http://us-support.external.hp.com/,
|
||||
for free copies of their latest patches.
|
||||
|
||||
@ -54,22 +54,23 @@ install on HPUX, so I recommend you not bother with anything older
|
||||
than 6.4.
|
||||
|
||||
|
||||
1.2) Anything special about the build/install procedure?
|
||||
1.2) Anything special about the build/install procedure?
|
||||
|
||||
When you run configure, you will want to explicitly select either the
|
||||
hpux_cc or hpux_gcc template depending on which compiler you plan to
|
||||
use:
|
||||
./configure --with-template=hpux_cc
|
||||
./configure --with-template=hpux_cc
|
||||
for HP's C compiler, or
|
||||
./configure --with-template=hpux_gcc
|
||||
./configure --with-template=hpux_gcc
|
||||
for GNU gcc. (If you omit --with-template, configure may either
|
||||
default to hpux_cc or give up entirely, depending on which HPUX and
|
||||
PostgreSQL releases you have.)
|
||||
|
||||
You may want to tweak the CFLAGS setting in template/hpux_[g]cc before
|
||||
you configure; the distributed files contain neither -O nor -g switches,
|
||||
which is hardly optimal for any situation. I've seen no problems using
|
||||
-O with gcc 2.7.2.*.
|
||||
you configure. The distributed copy of hpux_cc contains neither -O nor -g
|
||||
switches, which is hardly optimal for any situation. As of Postgres 6.5,
|
||||
hpux_gcc sets CFLAGS to -O2, which is fine unless you want to do debugging;
|
||||
in that case you may want -g as well (or instead).
|
||||
|
||||
The default install target location is /usr/local/pgsql, which
|
||||
(particularly on HPUX 10) you might want to change to something under
|
||||
@ -87,7 +88,7 @@ Otherwise the standard build/install procedure described in the
|
||||
PostgreSQL documentation works fine.
|
||||
|
||||
|
||||
1.3) yacc dies trying to process src/backend/parser/gram.y.
|
||||
1.3) yacc dies trying to process src/backend/parser/gram.y.
|
||||
|
||||
HP's yacc doesn't create its tables large enough to handle the Postgres
|
||||
grammar (a lot of other vendors' yaccs have this problem too). There
|
||||
@ -98,33 +99,37 @@ and src/backend/parser/parse.h and repeat the build. Any PostgreSQL
|
||||
distribution file should have up-to-date copies of those files included,
|
||||
so you shouldn't need to run yacc on gram.y at all ... but sometimes
|
||||
gram.y mistakenly has a newer timestamp in the distribution than the
|
||||
derived files do.
|
||||
derived files do. (If you fetched the PostgreSQL sources from the CVS
|
||||
server, then you won't have these files anyway; see next choices.)
|
||||
|
||||
2. Install "bison" (GNU yacc) and reconfigure. Bison doesn't have a
|
||||
problem with large grammars. Note this is not the right choice if you
|
||||
are using HP's cc on HPUX 9 --- see next item.
|
||||
|
||||
3. Increase yacc's table sizes enough to cope. With a pre-6.4
|
||||
2. Increase yacc's table sizes enough to cope. With a pre-6.4
|
||||
PostgreSQL grammar, I was able to get HPUX 9's yacc to work by
|
||||
setting YFLAGS to
|
||||
-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
|
||||
-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
|
||||
(You can edit YFLAGS either in the template file before running
|
||||
configure, or in src/Makefile.global afterwards.) Future PostgreSQL
|
||||
releases might require even larger tables, but this should do for
|
||||
a starting point.
|
||||
|
||||
3. Install "bison" (GNU yacc) and reconfigure. Bison doesn't have a
|
||||
problem with large grammars. Note this is not the right choice if you
|
||||
are using HP's cc on HPUX 9 --- see next item.
|
||||
|
||||
1.4) Linking the main postgres executable fails, complaining that
|
||||
there's no "alloca" function.
|
||||
|
||||
If you're using HP's cc on HPUX 9, it's right: there's no alloca
|
||||
function. The only place in PostgreSQL that uses alloca is the parser
|
||||
(gram.c), and that does so only if it was generated with GNU bison.
|
||||
Unfortunately the distribution copy of gram.c is made with bison.
|
||||
There are several possible answers:
|
||||
1.4) Linking the main postgres executable fails, complaining that
|
||||
there's no "alloca" function.
|
||||
|
||||
1. Remake gram.c with HP's yacc (see above item for switch settings).
|
||||
You might also need to remake src/backend/bootstrap/bootparse.c.
|
||||
If you're using HP's cc on HPUX 9, it's right: there's no alloca function.
|
||||
The only places in PostgreSQL that use alloca are the parser files, and
|
||||
those do so only if they were generated with GNU bison. Unfortunately the
|
||||
prebuilt copies of gram.c and preproc.c are made with bison. There are
|
||||
several possible answers:
|
||||
|
||||
1. Remake the files with HP's yacc: configure to use yacc with the
|
||||
above-mentioned switch settings, and remove these files before
|
||||
starting the build:
|
||||
src/backend/parser/gram.c
|
||||
src/interfaces/ecpg/preproc/preproc.c
|
||||
|
||||
2. Build with gcc, which treats alloca as a compiled-in-line function.
|
||||
|
||||
@ -132,7 +137,7 @@ There are several possible answers:
|
||||
before Y2K anyway...
|
||||
|
||||
|
||||
1.5) OK, it seemed to build and install, but the regression test fails.
|
||||
1.5) OK, it seemed to build and install, but the regression test fails.
|
||||
|
||||
There are several "expected failures" due to differences between HPUX
|
||||
and the regression test reference platform used by the PostgreSQL group.
|
||||
@ -140,32 +145,31 @@ A look at the textual differences between the expected and actual
|
||||
outputs will usually reveal that the differences are minor. You should
|
||||
expect these differences:
|
||||
|
||||
TEST(S) COMMENTS
|
||||
TEST(S) COMMENTS
|
||||
|
||||
int2, int4: pg_atoi generates a differently worded error
|
||||
message for integer overflow.
|
||||
int2, int4: pg_atoi generates a differently worded error
|
||||
message for integer overflow.
|
||||
|
||||
float8: In 6.4, float8 shows some differences due to
|
||||
different handling of overflow/underflow errors in
|
||||
exp() and pow(). This should be fixed in 6.4.1
|
||||
and later.
|
||||
float8, geometry: Lots of differences in the last digit or two
|
||||
because of different roundoff errors in floating
|
||||
arithmetic. Also, HPUX does not distinguish
|
||||
-0 from 0 during printout, but the reference
|
||||
platform does.
|
||||
|
||||
float8, geometry: Lots of differences in the last digit or two
|
||||
because of different roundoff errors in floating
|
||||
arithmetic. Also, HPUX does not distinguish
|
||||
-0 from 0 during printout, but the reference
|
||||
platform does.
|
||||
float8: In 6.4, float8 shows some differences due to
|
||||
different handling of overflow/underflow errors in
|
||||
exp() and pow(). This is fixed in 6.4.1 and later.
|
||||
|
||||
horology: HPUX time library does not know about daylight
|
||||
savings time before 1970, so there are some
|
||||
places in horology where a time will be shown
|
||||
in PST instead of PDT.
|
||||
horology: HPUX time library does not know about daylight
|
||||
savings time before 1970, so there are some
|
||||
places in horology where a time will be shown
|
||||
in PST instead of PDT.
|
||||
|
||||
In addition, the int8 regression test will fail massively on HPUX 9,
|
||||
because int8 doesn't actually work on this platform (sprintf/sscanf
|
||||
don't cope with long long int). Either upgrade to HPUX 10, or don't
|
||||
use int8 data.
|
||||
The int8 regression test will fail massively on HPUX 9 with Postgres 6.4,
|
||||
because sprintf/sscanf don't cope with long long int. This is fixed in
|
||||
Postgres 6.5 by not depending on the system versions of those routines.
|
||||
|
||||
Any other error is cause for suspicion. In particular, if you see
|
||||
failures in the datetime test on HPUX 9, you probably forgot to
|
||||
install the libm patch PHSS_4630 --- see item 1.1 above.
|
||||
</PRE>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user