postgresql/doc/src/sgml/postgres.sgml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

293 lines
7.9 KiB
Plaintext
Raw Permalink Normal View History

2010-09-20 22:08:53 +02:00
<!-- doc/src/sgml/postgres.sgml -->
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
[
<!ENTITY % version SYSTEM "version.sgml">
%version;
<!ENTITY % filelist SYSTEM "filelist.sgml">
%filelist;
<!ENTITY reference SYSTEM "reference.sgml">
<!--
Zero-width space. Use this to allow line breaks at desirable places in
table cells, examples, etc. without causing an unwanted space when the
break is not needed in a wider output rendering.
-->
<!ENTITY zwsp "&#x200B;">
1998-03-01 09:16:16 +01:00
]>
<book id="postgres">
<title>PostgreSQL &version; Documentation</title>
<bookinfo>
<corpauthor>The PostgreSQL Global Development Group</corpauthor>
<productname>PostgreSQL</productname>
<productnumber>&version;</productnumber>
&legal;
</bookinfo>
&intro;
<part id="tutorial">
<title>Tutorial</title>
<partintro>
<para>
Welcome to the <productname>PostgreSQL</productname> Tutorial. The
tutorial is intended to give an introduction
to <productname>PostgreSQL</productname>, relational database
concepts, and the SQL language. We assume some general knowledge about
how to use computers and no particular Unix or programming experience is
required. This tutorial is intended to provide hands-on experience with
important aspects of the <productname>PostgreSQL</productname> system.
It makes no attempt to be a comprehensive treatment of the topics it covers.
</para>
<para>
After you have successfully completed this tutorial you will want to
read the <xref linkend="sql"/> section to gain a better understanding
of the SQL language, or <xref linkend="client-interfaces"/> for
information about developing applications with
<productname>PostgreSQL</productname>. Those who provision and
manage their own PostgreSQL installation should also read <xref linkend="admin"/>.
</para>
</partintro>
&start;
&query;
&advanced;
</part>
<part id="sql">
<title>The SQL Language</title>
<partintro>
<para>
This part describes the use of the <acronym>SQL</acronym> language
in <productname>PostgreSQL</productname>. We start with
describing the general syntax of <acronym>SQL</acronym>, then
how to create tables, how to populate the database, and how to
query it. The middle part lists the available data types and
functions for use in <acronym>SQL</acronym> commands. Lastly,
we address several aspects of importance for tuning a database.
</para>
<para>
The information is arranged so that a novice user can
follow it from start to end and gain a full understanding of the topics
without having to refer forward too many times. The chapters are
intended to be self-contained, so that advanced users can read the
chapters individually as they choose. The information is presented
in narrative form with topical units. Readers looking for a complete
description of a particular command are encouraged to review
the <xref linkend="reference"/>.
</para>
<para>
Readers should know how to connect to a
<productname>PostgreSQL</productname> database and issue
<acronym>SQL</acronym> commands. Readers that are unfamiliar with
these issues are encouraged to read <xref linkend="tutorial"/>
first. <acronym>SQL</acronym> commands are typically entered
using the <productname>PostgreSQL</productname> interactive terminal
<application>psql</application>, but other programs that have
similar functionality can be used as well.
</para>
</partintro>
&syntax;
&ddl;
&dml;
&queries;
&datatype;
&func;
&typeconv;
&indices;
&textsearch;
&mvcc;
&perform;
&parallel;
</part>
<part id="admin">
<title>Server Administration</title>
<partintro>
<para>
This part covers topics that are of interest to a
<productname>PostgreSQL</productname> administrator. This includes
installation, configuration of the server, management of users
and databases, and maintenance tasks. Anyone running
<productname>PostgreSQL</productname> server, even for
personal use, but especially in production, should be familiar
with these topics.
</para>
<para>
The information attempts to be in the order in which
a new user should read it. The chapters are self-contained and
can be read individually as desired. The information is presented
in a narrative form in topical units. Readers looking for a complete
description of a command are encouraged to review the
<xref linkend="reference"/>.
</para>
<para>
The first few chapters are written so they can be understood
without prerequisite knowledge, so new users who need to set
up their own server can begin their exploration. The rest of this
part is about tuning and management; that material
2004-12-24 20:12:37 +01:00
assumes that the reader is familiar with the general use of
the <productname>PostgreSQL</productname> database system. Readers are
encouraged review the <xref linkend="tutorial"/> and <xref
linkend="sql"/> parts for additional information.
</para>
</partintro>
&installbin;
&installation;
&runtime;
&config;
&client-auth;
&user-manag;
&manage-ag;
&charset;
&maintenance;
&backup;
&high-availability;
&monitoring;
&wal;
&logical-replication;
&jit;
&regress;
</part>
<part id="client-interfaces">
<title>Client Interfaces</title>
<partintro>
<para>
This part describes the client programming interfaces distributed
with <productname>PostgreSQL</productname>. Each of these chapters can be
read independently. There are many external programming
interfaces for client programs that are distributed separately. They
contain their own documentation (<xref linkend="external-projects"/>
lists some of the more popular ones). Readers of this part should be
familiar with using <acronym>SQL</acronym> to manipulate
and query the database (see <xref linkend="sql"/>) and of course
with the programming language of their choice.
</para>
</partintro>
&libpq;
&lobj;
&ecpg;
&infoschema;
</part>
<part id="server-programming">
<title>Server Programming</title>
<partintro>
<para>
This part is about extending the server functionality with
user-defined functions, data types, triggers, etc. These are
advanced topics which should be approached only after all
the other user documentation about <productname>PostgreSQL</productname> has
been understood. Later chapters in this part describe the server-side
programming languages available in the
<productname>PostgreSQL</productname> distribution as well as
general issues concerning server-side programming. It
is essential to read at least the earlier sections of <xref
linkend="extend"/> (covering functions) before diving into the
material about server-side programming.
</para>
</partintro>
&extend;
&trigger;
&event-trigger;
&rules;
&xplang;
&plsql;
&pltcl;
&plperl;
&plpython;
&spi;
Background worker processes Background workers are postmaster subprocesses that run arbitrary user-specified code. They can request shared memory access as well as backend database connections; or they can just use plain libpq frontend database connections. Modules listed in shared_preload_libraries can register background workers in their _PG_init() function; this is early enough that it's not necessary to provide an extra GUC option, because the necessary extra resources can be allocated early on. Modules can install more than one bgworker, if necessary. Care is taken that these extra processes do not interfere with other postmaster tasks: only one such process is started on each ServerLoop iteration. This means a large number of them could be waiting to be started up and postmaster is still able to quickly service external connection requests. Also, shutdown sequence should not be impacted by a worker process that's reasonably well behaved (i.e. promptly responds to termination signals.) The current implementation lets worker processes specify their start time, i.e. at what point in the server startup process they are to be started: right after postmaster start (in which case they mustn't ask for shared memory access), when consistent state has been reached (useful during recovery in a HOT standby server), or when recovery has terminated (i.e. when normal backends are allowed). In case of a bgworker crash, actions to take depend on registration data: if shared memory was requested, then all other connections are taken down (as well as other bgworkers), just like it were a regular backend crashing. The bgworker itself is restarted, too, within a configurable timeframe (which can be configured to be never). More features to add to this framework can be imagined without much effort, and have been discussed, but this seems good enough as a useful unit already. An elementary sample module is supplied. Author: Álvaro Herrera This patch is loosely based on prior patches submitted by KaiGai Kohei, and unsubmitted code by Simon Riggs. Reviewed by: KaiGai Kohei, Markus Wanner, Andres Freund, Heikki Linnakangas, Simon Riggs, Amit Kapila
2012-12-06 18:57:52 +01:00
&bgworker;
&logicaldecoding;
Introduce replication progress tracking infrastructure. When implementing a replication solution ontop of logical decoding, two related problems exist: * How to safely keep track of replication progress * How to change replication behavior, based on the origin of a row; e.g. to avoid loops in bi-directional replication setups The solution to these problems, as implemented here, consist out of three parts: 1) 'replication origins', which identify nodes in a replication setup. 2) 'replication progress tracking', which remembers, for each replication origin, how far replay has progressed in a efficient and crash safe manner. 3) The ability to filter out changes performed on the behest of a replication origin during logical decoding; this allows complex replication topologies. E.g. by filtering all replayed changes out. Most of this could also be implemented in "userspace", e.g. by inserting additional rows contain origin information, but that ends up being much less efficient and more complicated. We don't want to require various replication solutions to reimplement logic for this independently. The infrastructure is intended to be generic enough to be reusable. This infrastructure also replaces the 'nodeid' infrastructure of commit timestamps. It is intended to provide all the former capabilities, except that there's only 2^16 different origins; but now they integrate with logical decoding. Additionally more functionality is accessible via SQL. Since the commit timestamp infrastructure has also been introduced in 9.5 (commit 73c986add) changing the API is not a problem. For now the number of origins for which the replication progress can be tracked simultaneously is determined by the max_replication_slots GUC. That GUC is not a perfect match to configure this, but there doesn't seem to be sufficient reason to introduce a separate new one. Bumps both catversion and wal page magic. Author: Andres Freund, with contributions from Petr Jelinek and Craig Ringer Reviewed-By: Heikki Linnakangas, Petr Jelinek, Robert Haas, Steve Singer Discussion: 20150216002155.GI15326@awork2.anarazel.de, 20140923182422.GA15776@alap3.anarazel.de, 20131114172632.GE7522@alap2.anarazel.de
2015-04-29 19:30:53 +02:00
&replication-origins;
&archive-modules;
</part>
&reference;
<part id="internals">
<title>Internals</title>
<partintro>
<para>
This part contains assorted information that might be of use to
<productname>PostgreSQL</productname> developers.
</para>
</partintro>
&arch-dev;
&catalogs;
&system-views;
&protocol;
&sources;
&nls;
&plhandler;
&fdwhandler;
Redesign tablesample method API, and do extensive code review. The original implementation of TABLESAMPLE modeled the tablesample method API on index access methods, which wasn't a good choice because, without specialized DDL commands, there's no way to build an extension that can implement a TSM. (Raw inserts into system catalogs are not an acceptable thing to do, because we can't undo them during DROP EXTENSION, nor will pg_upgrade behave sanely.) Instead adopt an API more like procedural language handlers or foreign data wrappers, wherein the only SQL-level support object needed is a single handler function identified by having a special return type. This lets us get rid of the supporting catalog altogether, so that no custom DDL support is needed for the feature. Adjust the API so that it can support non-constant tablesample arguments (the original coding assumed we could evaluate the argument expressions at ExecInitSampleScan time, which is undesirable even if it weren't outright unsafe), and discourage sampling methods from looking at invisible tuples. Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable within and across queries, as required by the SQL standard, and deal more honestly with methods that can't support that requirement. Make a full code-review pass over the tablesample additions, and fix assorted bugs, omissions, infelicities, and cosmetic issues (such as failure to put the added code stanzas in a consistent ordering). Improve EXPLAIN's output of tablesample plans, too. Back-patch to 9.5 so that we don't have to support the original API in production.
2015-07-25 20:39:00 +02:00
&tablesample-method;
&custom-scan;
&geqo;
&tableam;
&indexam;
&wal-for-extensions;
&indextypes;
&storage;
&transaction;
&bki;
&planstats;
&backup-manifest;
</part>
<part id="appendixes">
<title>Appendixes</title>
&errcodes;
&datetime;
&keywords;
&features;
&release;
&contrib;
&external-projects;
&sourcerepo;
&docguide;
&limits;
&acronyms;
&glossary;
&color;
&obsolete;
</part>
&biblio;
<index id="bookindex"></index>
</book>