<para>
Returns the process <acronym>ID</acronym>
(PID)<indexterm><primary>PID</><secondary>determining PID of
- server process</><tertiary>in libpq</></> of the backend server
+ server process</><tertiary>in libpq</></> of the backend
process handling this connection.
<synopsis>
</listitem>
</itemizedlist>
- Here <quote>program</quote> refers to any executable, not only the backend server.
+ Here <quote>program</quote> refers to any executable, not only the backend process.
</para>
<para>
When writing a bug report, please avoid confusing terminology.
The software package in total is called <quote>PostgreSQL</quote>,
sometimes <quote>Postgres</quote> for short. If you
- are specifically talking about the backend server, mention that, do not
+ are specifically talking about the backend process, mention that, do not
just say <quote>PostgreSQL crashes</quote>. A crash of a single
- backend server process is quite different from crash of the parent
+ backend process is quite different from crash of the parent
<quote>postgres</> process; please don't say <quote>the server
crashed</> when you mean a single backend process went down, nor vice versa.
Also, client programs such as the interactive frontend <quote><application>psql</application></quote>
COPY weather FROM '/home/user/weather.txt';
</programlisting>
- where the file name for the source file must be available to the
- backend server machine, not the client, since the backend server
+ where the file name for the source file must be available on the
+ machine running the backend process, not the client, since the backend process
reads the file directly. You can read more about the
<command>COPY</command> command in <xref linkend="sql-copy">.
</para>
<application>pg_ctl</application> is a utility for initializing a
<productname>PostgreSQL</productname> database cluster, starting,
stopping, or restarting the <productname>PostgreSQL</productname>
- backend server (<xref linkend="app-postgres">), or displaying the
+ database server (<xref linkend="app-postgres">), or displaying the
status of a running server. Although the server can be started
manually, <application>pg_ctl</application> encapsulates tasks such
as redirecting log output and properly detaching from the terminal
* how to handle signalling.
*
* signal(2) handling - this is here because it affects some of
- * the frontend commands as well as the backend server.
+ * the frontend commands as well as the backend processes.
*
* Ultrix and SunOS provide BSD signal(2) semantics by default.
*
printf(_(" -O allow system table structure changes\n"));
printf(_(" -P disable system indexes\n"));
printf(_(" -t pa|pl|ex show timings after each query\n"));
- printf(_(" -T send SIGSTOP to all backend servers if one dies\n"));
+ printf(_(" -T send SIGSTOP to all backend processes if one dies\n"));
printf(_(" -W NUM wait NUM seconds to allow attach from a debugger\n"));
printf(_("\nOptions for single-user mode:\n"));
* defaults by looking up environment variables or, failing that, using
* hardwired constants
*/
- pghost = NULL; /* host name of the backend server */
- pgport = NULL; /* port of the backend server */
+ pghost = NULL; /* host name of the backend */
+ pgport = NULL; /* port of the backend */
pgoptions = NULL; /* special options to start up the backend
* server */
- pgtty = NULL; /* debugging tty for the backend server */
+ pgtty = NULL; /* debugging tty for the backend */
/* make a connection to the database */
conn1 = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName1);