ecpg new portable FETCH syntax
Add ecpg EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF
and EXEC SQL ENDIF directives
-Add pg_ctl script to control backend startup (Tatsuo)
-Add postmaster.opts.default file to store startup flags (Tatsuo)
+Add pg_ctl script to control backend start-up (Tatsuo)
+Add postmaster.opts.default file to store start-up flags (Tatsuo)
Allow --with-mb=SQL_ASCII
Increase maximum number of index keys to 16 (Bruce)
Increase maximum number of function arguments to 16 (Bruce)
Major speedup in vacuum of deleted rows with indexes(Vadim)
Allow non-SQL functions to run different versions based on arguments(Tom)
Add -E option that shows actual queries sent by \dt and friends(Masaaki Sakaida)
-Add version number in startup banners for psql(Masaaki Sakaida)
+Add version number in start-up banners for psql(Masaaki Sakaida)
New contrib/vacuumlo removes large objects not referenced(Peter)
New initialization for table sizes so non-vacuumed tables perform better(Tom)
Improve error messages when a connection is rejected(Tom)
Enable assert checking without a recompile(Massimo)
User lock enhancements(Massimo)
New setval() command to set sequence value(Massimo)
-Auto-remove unix socket file on startup if no postmaster running(Massimo)
+Auto-remove unix socket file on start-up if no postmaster running(Massimo)
Conditional trace package(Massimo)
New UNLISTEN command(Massimo)
Psql and libpq now compile under win32 using win32.mak(Magnus)
Add new psql \da, \dd, \df, \do, \dS, and \dT commands(Bruce)
Enhance psql \z to show sequences(Bruce)
Show NOT NULL and DEFAULT in psql \d table(Bruce)
-New psql .psqlrc file startup(Andrew)
-Modify sample startup script in contrib/linux to show syslog(Thomas)
+New psql .psqlrc file start-up(Andrew)
+Modify sample start-up script in contrib/linux to show syslog(Thomas)
New types for IP and MAC addresses in contrib/ip_and_mac(TomH)
Unix system time conversions with date/time types in contrib/unixdate(Thomas)
Update of contrib stuff(Massimo)
Added conversion routines circle(box) and poly(circle)(Thomas)
Allow internal sorts to be stored in memory rather than in files(Bruce & Vadim)
Allow functions and operators on internally-identical types to succeed(Bruce)
-Speed up backend startup after profiling analysis(Bruce)
+Speed up backend start-up after profiling analysis(Bruce)
Inline frequently called functions for performance(Bruce)
Reduce open() calls(Bruce)
psql: Add PAGER for \h and \?,\C fix
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.34 2000/08/24 23:36:28 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.35 2000/08/29 20:02:07 momjian Exp $
-->
<chapter id="datatype">
<listitem>
<para>
The <envar>PGDATESTYLE</envar> environment variable used by the backend directly
- on postmaster startup.
+ on postmaster start-up.
</para>
</listitem>
<listitem>
<para>
The <envar>PGDATESTYLE</envar> environment variable used by the frontend libpq
- on session startup.
+ on session start-up.
</para>
</listitem>
<listitem>
<listitem>
<para>
The TZ environment variable used by the backend directly
- on postmaster startup as the default time zone.
+ on postmaster start-up as the default time zone.
</para>
</listitem>
<listitem>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.8 2000/05/02 20:01:51 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.9 2000/08/29 20:02:07 momjian Exp $
-->
<sect1>
<listitem>
<para>
Overall backend code speed has been increased by approximately 20-40%,
- and backend startup time has decreased 80% since v6.0 was released.
+ and backend start-up time has decreased 80% since v6.0 was released.
</para>
</listitem>
</itemizedlist>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.3 2000/03/31 17:18:26 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/indexcost.sgml,v 2.4 2000/08/29 20:02:07 momjian Exp $
-->
<chapter>
<term>*indexStartupCost</term>
<listitem>
<para>
- Set to cost of index startup processing
+ Set to cost of index start-up processing
</para>
</listitem>
</varlistentry>
</para>
<para>
- The "startup cost" is the part of the total scan cost that must be expended
+ The "start-up cost" is the part of the total scan cost that must be expended
before we can begin to fetch the first tuple. For most indexes this can
- be taken as zero, but an index type with a high startup cost might want
+ be taken as zero, but an index type with a high start-up cost might want
to set it nonzero.
</para>
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.15 2000/08/29 04:15:43 momjian Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.16 2000/08/29 20:02:07 momjian Exp $ -->
<chapter id="installation">
<title><![%flattext-install-include[<productname>PostgreSQL</> ]]>Installation Instructions</title>
<para>
On systems which have <productname>PostgreSQL</> started at boot time, there is
- probably a startup file that will accomplish the same thing. For
+ probably a start-up file that will accomplish the same thing. For
example, on a Redhat Linux system one might find that
<programlisting>
/etc/rc.d/init.d/postgres.init stop
</programlisting>
Replace <literal>/usr/local/pgsql/lib</> with whatever you set
<option><literal>--libdir</></> to in <xref linkend="configure">.
- You should put these commands into a shell startup file such as
+ You should put these commands into a shell start-up file such as
<filename>/etc/profile</> or <filename>~/.bash_profile</>.
</para>
add <filename>/usr/local/pgsql/bin</> (or what you set
<option><literal>--bindir</></> to in <xref linkend="configure">)
into your <envar>PATH</>. To do this, add the following to your
- shell startup file, such as <filename>~/.bash_profile</> (or
+ shell start-up file, such as <filename>~/.bash_profile</> (or
<filename>/etc/profile</>, if you want it to affect every user):
<programlisting>
PATH=$PATH:/usr/local/pgsql/bin
<para>
To enable your system to find the <application>man</>
documentation, you need to add a line like the following to a
- shell startup file:
+ shell start-up file:
<programlisting>
MANPATH=$MANPATH:/usr/local/pgsql/man
</programlisting>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.11 2000/08/23 05:59:02 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.12 2000/08/29 20:02:07 momjian Exp $
-->
<chapter id="jdbc">
keeping connection times as fast as possible.
The postgresql.LargeObject class performs a query upon it's
-startup, and passes the returned ResultSet to the addFunctions()
+start-up, and passes the returned ResultSet to the addFunctions()
method here.
Once this has been done, the LargeObject api refers to the
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.39 2000/08/29 04:15:43 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.40 2000/08/29 20:02:07 momjian Exp $
-->
<chapter id="libpq-chapter">
</listitem>
<listitem>
<para>
- CONNECTION_AUTH_OK: Received authentication; waiting for backend startup.
+ CONNECTION_AUTH_OK: Received authentication; waiting for backend start-up.
</para>
</listitem>
<listitem>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.9 2000/06/30 16:14:21 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/manage-ag.sgml,v 2.10 2000/08/29 20:02:07 momjian Exp $
-->
<chapter id="managing-databases">
in csh or tcsh. You have to make sure that this environment
variable is always defined in the server environment, otherwise
you won't be able to access that database. Therefore you probably
- want to set it in some sort of shell startup file or server
- startup script.
+ want to set it in some sort of shell start-up file or server
+ start-up script.
</para>
<para>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.15 2000/05/02 20:01:52 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/odbc.sgml,v 1.16 2000/08/29 20:02:07 momjian Exp $
-->
<chapter id="odbc">
<para>
You can add information about your
- database login and password to the standard Applix startup
+ database login and password to the standard Applix start-up
macro file. This is an example
<filename>~/axhome/macros/login.am</filename> file:
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.3 2000/03/31 17:45:00 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plan.sgml,v 2.4 2000/08/29 20:02:07 momjian Exp $
-->
<chapter>
<itemizedlist>
<listitem>
<para>
- Estimated startup cost (time expended before output scan can start,
+ Estimated start-up cost (time expended before output scan can start,
eg, time to do the sorting in a SORT node).
</para>
</listitem>
using ye same olde indexscan, stash them into an in-memory hash table,
and then do a sequential scan of tenk2, probing into the hash table
for possible matches of "t1.unique2 = t2.unique2" at each tenk2 tuple.
- The cost to read tenk1 and set up the hash table is entirely startup
+ The cost to read tenk1 and set up the hash table is entirely start-up
cost for the hash join, since we won't get any tuples out until we can
start reading tenk2. The total time estimate for the join also
includes a pretty hefty charge for CPU time to probe the hash table
<itemizedlist>
<listitem>
<para>
- The exact sequence of steps <emphasis>from program startup</emphasis>
+ The exact sequence of steps <emphasis>from program start-up</emphasis>
necessary to reproduce the problem. This should be self-contained;
it is not enough to send in a bare select statement without the
preceeding create table and insert statements, if the output should
query-language related problems is a file that can be run through the
<application>psql</application> frontend
that shows the problem. (Be sure to not have anything in your
- <filename>~/.psqlrc</filename> startup file.) You are encouraged to
+ <filename>~/.psqlrc</filename> start-up file.) You are encouraged to
minimize the size of your example, but this is not absolutely necessary.
If the bug is reproduceable, we'll find it either way.
</para>
<listitem>
<para>
- Any command line options and other startup options, including concerned
+ Any command line options and other start-up options, including concerned
environment variables or configuration files that you changed from the
default. Again, be exact. If you are using a pre-packaged
distribution that starts the database server at boot time, you should try
</para>
<Para>
-A frontend sends a startup packet to the postmaster. This includes the names
+A frontend sends a start-up packet to the postmaster. This includes the names
of the user and the database the user wants to connect to. The postmaster then
uses this, and the information in the <filename>pg_hba.conf</filename>
file
The frontend then sends any required authentication information. Once the
postmaster validates this it responds to the frontend that it is authenticated
and hands over the connection to a backend. The backend then sends a message
-indicating successful startup (normal case) or failure (for example, an
+indicating successful start-up (normal case) or failure (for example, an
invalid database name).
</para>
<Para>
This section describes the message flow. There are four different types of
flows depending on the state of the connection:
-startup, query, function call, and termination.
+start-up, query, function call, and termination.
There are also special provisions for notification responses and command
-cancellation, which can occur at any time after the startup phase.
+cancellation, which can occur at any time after the start-up phase.
</para>
<Sect2>
-<Title>Startup</Title>
+<Title>Start-up</Title>
<Para>
-Startup is divided into an authentication phase and a backend startup phase.
+Start-up is divided into an authentication phase and a backend start-up phase.
</para>
<Para>
<Para>
After sending AuthenticationOk, the postmaster attempts to launch a backend
process. Since this might fail, or the backend might encounter a failure
-during startup, the frontend must wait for the backend to acknowledge
-successful startup. The frontend should send no messages at this point.
+during start-up, the frontend must wait for the backend to acknowledge
+successful start-up. The frontend should send no messages at this point.
The possible messages from the backend during this phase are:
<VariableList>
</Term>
<ListItem>
<Para>
- This message is issued after successful backend startup.
+ This message is issued after successful backend start-up.
It provides secret-key data that the frontend must save
if it wants to be able to issue cancel requests later.
The frontend should not respond to this message, but should
</Term>
<ListItem>
<Para>
- Backend startup is successful. The frontend may now issue
+ Backend start-up is successful. The frontend may now issue
query or function call messages.
</Para>
</ListItem>
</Term>
<ListItem>
<Para>
- Backend startup failed. The connection is closed after
+ Backend start-up failed. The connection is closed after
sending this message.
</Para>
</ListItem>
The ReadyForQuery message is the same one that the backend will issue after
each query cycle. Depending on the coding needs of the frontend, it is
reasonable to consider ReadyForQuery as starting a query cycle (and then
-BackendKeyData indicates successful conclusion of the startup phase),
-or to consider ReadyForQuery as ending the startup phase and each subsequent
+BackendKeyData indicates successful conclusion of the start-up phase),
+or to consider ReadyForQuery as ending the start-up phase and each subsequent
query cycle.
</para>
</sect2>
<Para>
Notification responses are permitted at any point in the protocol (after
-startup), except within another backend message. Thus, the frontend
+start-up), except within another backend message. Thus, the frontend
must be prepared to recognize a NotificationResponse message whenever it is
expecting any message. Indeed, it should be able to handle
NotificationResponse messages even when it is not engaged in a query.
<Para>
A CancelRequest message will be ignored unless it contains the same key data
-(PID and secret key) passed to the frontend during connection startup. If the
+(PID and secret key) passed to the frontend during connection start-up. If the
request matches the PID and secret key for a currently executing backend, the
postmaster signals the backend to abort processing of the current query.
</para>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/explain.sgml,v 1.9 2000/02/15 23:37:49 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/explain.sgml,v 1.10 2000/08/29 20:02:09 momjian Exp $
Postgres documentation
-->
The most critical part of the display is the estimated query execution
cost, which is the planner's guess at how long it will take to run the
query (measured in units of disk page fetches). Actually two numbers
- are shown: the startup time before the first tuple can be returned, and
+ are shown: the start-up time before the first tuple can be returned, and
the total time to return all the tuples. For most queries the total time
is what matters, but in contexts such as an EXISTS sub-query the planner
- will choose the smallest startup time instead of the smallest total time
+ will choose the smallest start-up time instead of the smallest total time
(since the executor will stop after getting one tuple, anyway).
Also, if you limit the number of tuples to return with a LIMIT clause,
the planner makes an appropriate interpolation between the endpoint
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pgctl-ref.sgml,v 1.6 2000/07/22 04:30:27 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pgctl-ref.sgml,v 1.7 2000/08/29 20:02:09 momjian Exp $
Postgres documentation
-->
<para>
Immediate mode sends SIGUSR1
to the backends and lets them abort. In this case, database recovery
- will be necessary on the next startup.
+ will be necessary on the next start-up.
</para>
</listitem>
</varlistentry>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.35 2000/07/22 04:45:09 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.36 2000/08/29 20:02:09 momjian Exp $
Postgres documentation
-->
In general, both will do what you expect, but using <literal>-f</literal>
enables some nice features such as error messages with line numbers.
There is also a slight chance that using this option will reduce
- the startup overhead. On the other hand, the variant using the shell's
+ the start-up overhead. On the other hand, the variant using the shell's
input redirection is (in theory) guaranteed to yield exactly the same
output that you would have gotten had you entered everything by hand.
</para>
Performs a variable assignment, like the <command>\set</command> internal command.
Note that you must separate name and value, if any, by an equal sign on the command
line. To unset a variable, leave off the equal sign. These assignments are done
- during a very early state of startup, so variables reserved for internal purposes
+ during a very early state of start-up, so variables reserved for internal purposes
might get overwritten later.
</para>
</listitem>
<term>-X, --no-psqlrc</term>
<listitem>
<para>
- Do not read the startup file <filename>~/.psqlrc</filename>.
+ Do not read the start-up file <filename>~/.psqlrc</filename>.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
The name of the database you are currently connected to. This is set every time
- you connect to a database (including program startup), but can be unset.
+ you connect to a database (including program start-up), but can be unset.
</para>
</listitem>
</varlistentry>
<para>
If set to <quote><literal>all</literal></quote>, all lines entered or from a script
are written to the standard output before they
- are parsed or executed. To specify this on program startup, use the switch
+ are parsed or executed. To specify this on program start-up, use the switch
<option>-a</option>. If set to <quote><literal>queries</literal></quote>,
<application>psql</application> merely prints all queries as they are sent to the
backend. The option for this is <option>-e</option>.
<listitem>
<para>
The database server host you are currently connected to. This is set every time
- you connect to a database (including program startup), but can be unset.
+ you connect to a database (including program start-up), but can be unset.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
The database server port to which you are currently connected. This is set every time
- you connect to a database (including program startup), but can be unset.
+ you connect to a database (including program start-up), but can be unset.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
The database user you are currently connected as. This is set every time
- you connect to a database (including program startup), but can be unset.
+ you connect to a database (including program start-up), but can be unset.
</para>
</listitem>
</varlistentry>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/set.sgml,v 1.47 2000/08/07 00:51:18 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/set.sgml,v 1.48 2000/08/29 20:02:09 momjian Exp $
Postgres documentation
-->
Setting the <envar>PGDATESTYLE</envar> environment variable.
If PGDATESTYLE is set in the frontend environment of a client
based on libpq, libpq will automatically set DATESTYLE to the
- value of PGDATESTYLE during connection startup.
+ value of PGDATESTYLE during connection start-up.
</member>
<member>
Running postmaster using the option <option>-o -e</option> to
<para>
If the PGTZ environment variable is set in the frontend
environment of a client based on libpq, libpq will automatically
- set TIMEZONE to the value of PGTZ during connection startup.
+ set TIMEZONE to the value of PGTZ during connection start-up.
</para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
- <term><computeroutput>ERROR: <replaceable>name</replaceable> can only be set at startup</computeroutput></term>
+ <term><computeroutput>ERROR: <replaceable>name</replaceable> can only be set at start-up</computeroutput></term>
<listitem>
<para>
Some parameters are fixed once the server is started.
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.57 2000/07/14 16:04:18 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.58 2000/08/29 20:02:07 momjian Exp $
-->
<chapter id="release">
ecpg new portable FETCH syntax
Add ecpg EXEC SQL IFDEF, EXEC SQL IFNDEF, EXEC SQL ELSE, EXEC SQL ELIF
and EXEC SQL ENDIF directives
-Add pg_ctl script to control backend startup (Tatsuo)
-Add postmaster.opts.default file to store startup flags (Tatsuo)
+Add pg_ctl script to control backend start-up (Tatsuo)
+Add postmaster.opts.default file to store start-up flags (Tatsuo)
Allow --with-mb=SQL_ASCII
Increase maximum number of index keys to 16 (Bruce)
Increase maximum number of function arguments to 16 (Bruce)
Major speedup in vacuum of deleted rows with indexes(Vadim)
Allow non-SQL functions to run different versions based on arguments(Tom)
Add -E option that shows actual queries sent by \dt and friends(Masaaki Sakaida)
-Add version number in startup banners for psql(Masaaki Sakaida)
+Add version number in start-up banners for psql(Masaaki Sakaida)
New contrib/vacuumlo removes large objects not referenced(Peter)
New initialization for table sizes so non-vacuumed tables perform better(Tom)
Improve error messages when a connection is rejected(Tom)
Enable assert checking without a recompile(Massimo)
User lock enhancements(Massimo)
New setval() command to set sequence value(Massimo)
-Auto-remove unix socket file on startup if no postmaster running(Massimo)
+Auto-remove unix socket file on start-up if no postmaster running(Massimo)
Conditional trace package(Massimo)
New UNLISTEN command(Massimo)
Psql and libpq now compile under win32 using win32.mak(Magnus)
Add new psql \da, \dd, \df, \do, \dS, and \dT commands(Bruce)
Enhance psql \z to show sequences(Bruce)
Show NOT NULL and DEFAULT in psql \d table(Bruce)
-New psql .psqlrc file startup(Andrew)
-Modify sample startup script in contrib/linux to show syslog(Thomas)
+New psql .psqlrc file start-up(Andrew)
+Modify sample start-up script in contrib/linux to show syslog(Thomas)
New types for IP and MAC addresses in contrib/ip_and_mac(TomH)
Unix system time conversions with date/time types in contrib/unixdate(Thomas)
Update of contrib stuff(Massimo)
Added conversion routines circle(box) and poly(circle)(Thomas)
Allow internal sorts to be stored in memory rather than in files(Bruce & Vadim)
Allow functions and operators on internally-identical types to succeed(Bruce)
-Speed up backend startup after profiling analysis(Bruce)
+Speed up backend start-up after profiling analysis(Bruce)
Inline frequently called functions for performance(Bruce)
Reduce open() calls(Bruce)
psql: Add PAGER for \h and \?,\C fix
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.22 2000/08/29 04:15:43 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.23 2000/08/29 20:02:07 momjian Exp $
-->
<Chapter Id="runtime">
</para>
<sect2 id="postmaster-start-failures">
- <title>Server Startup Failures</title>
+ <title>Server Start-up Failures</title>
<para>
There are several common reasons for the postmaster to fail to
will cause the postmaster to send a SIGUSR1 to all backends and
exit immediately (without properly shutting down the database
system). When WAL is implemented, this will lead to recovery on
- startup. Right now it's not recommendable to use this option.
+ start-up. Right now it's not recommendable to use this option.
</para>
</listitem>
</varlistentry>
Fill out the information the script asks for. Make sure to enter
the local hostname as Common Name. The script will generate a key
which is passphrase protected. To remove the passphrase (required
- if you want automatic startup of the postmaster), run the command
+ if you want automatic start-up of the postmaster), run the command
<programlisting>
openssl x509 -inform PEM -outform PEM -in newreq.pem -out newkey_no_passphrase.pem
</programlisting>
projects / postgresql / commitdiff