</indexterm>

<para>

of using SPI and triggers. While these functions are of some value in

their own right, they are even more useful as examples to modify for

your own purposes. The functions are general enough to be used

<productname>PostgreSQL</productname> provides storage and comparison

functions for UUIDs, but the core database does not include any

function for generating UUIDs, because no single algorithm is well

Alternatively, UUIDs could be generated by client applications or

other libraries invoked through a server-side function.

</para>

</refsect1>

</refentry>

<refmeta>

<refentrytitle>dblink</refentrytitle>

<manvolnum>3</manvolnum>

<para>

You can monitor disk space in three ways:

using the SQL functions listed in <xref linkend="functions-admin-dbsize">,

using manual inspection of the system catalogs.

The SQL functions are the easiest to use and are generally recommended.

The remainder of this section shows how to do it by inspection of the

system catalogs.

</para>

sections is to use a <varname>restore_command</> that polls the archive location.

This was the only option available in versions 8.4 and below. In this

setup, set <varname>standby_mode</> off, because you are implementing

implementation of this.

</para>

<para>

A working example of a waiting <varname>restore_command</> is provided

should be used as a reference on how to correctly implement the logic

described above. It can also be extended as needed to support specific

configurations and environments.

primary server and keep a query active for as long as needed to

run queries on the standby. This prevents <command>VACUUM</> from removing

recently-dead rows and so cleanup conflicts do not occur.

<function>pg_sleep()</>, or via other mechanisms. If you do this, you

should note that this will delay cleanup of dead rows on the primary,

which may result in undesirable table bloat. However, the cleanup

<listitem>

<para>

Use the <ulink url="http://www.ossp.org/pkg/lib/uuid/">OSSP UUID

UUIDs.<indexterm><primary>UUID</primary></indexterm>

</para>

</listitem>

<term><option>--with-libxslt</option></term>

<listitem>

<para>

</para>

</listitem>

</varlistentry>

<para>

If you already have, or suspect you have, orphaned large objects, see the

you clean them up. It's a good idea to run <application>vacuumlo</>

occasionally as a back-stop to the <function>lo_manage</> trigger.

</para>

AS t1(proname name, prosrc text)

WHERE proname LIKE 'bytea%';

</programlisting>

<type>record</> since it might be used for any kind of query.

The actual column set must be specified in the calling query so

that the parser knows, for example, what <literal>*</> should

may be safely removed.

This information can be used to truncate the archive to just the

minimum required to support restart from the current restore.

single-standby configurations, for example:

<programlisting> archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r' </programlisting>

Note however that if multiple standby servers are restoring from the

<para>

The following example command defines a GiST index operator class

</para>

<programlisting>

<listitem>

<para>

This is useful if only some of the data is sensitive.

The client supplies the decryption key and the data is decrypted

on the server and then sent to the client.

using <function>SPI_exec</function> and returns the number of rows

that were processed by the command. You can find more complex

examples for SPI in the source tree in

</para>

<programlisting>

<para>

See <filename>src/backend/storage/freespace/README</> for more details on

how the <acronym>FSM</> is structured, and how it's updated and searched.

</para>

</sect1>

end where it'd be useless. Filtering dictionaries are useful to partially

normalize words to simplify the task of later dictionaries. For example,

a filtering dictionary could be used to remove accents from accented

</para>

<sect2 id="textsearch-stopwords">

allows the implementation of very fast searches with online update.

Partitioning can be done at the database level using table inheritance,

or by distributing documents over

only local information.

</para>

<title>Migration from Pre-8.3 Text Search</title>

<para>

built-in features:

</para>

argument lists, and all of them are now in the <literal>pg_catalog</>

schema, whereas in a previous installation they would have been in

<literal>public</> or another non-system schema. There is a new

that provides a compatibility layer to solve most problems in this

area.

</para>

</listitem>

<listitem>

<para>

<emphasis>must</> be suppressed when loading <application>pg_dump</>

output from a pre-8.3 database. While many of them won't load anyway,

a few will and then cause problems. One simple way to deal with this

the dump; then it will block the old objects from being loaded.

</para>

</listitem>

<para>

There are more complex examples in

<filename>src/test/regress/regress.c</filename> and

</para>

</sect1>

</chapter>

</indexterm>

<para>

text search functionality for applications that used

into core <productname>PostgreSQL</productname> in release 8.3.

</para>

<para>

Although the built-in text search features were based on

there are numerous small differences that will create portability

issues for existing applications:

</para>

<para>

The built-in text search data types and functions all exist within

the system schema <literal>pg_catalog</>. In an installation using

the <literal>public</> schema, though some users chose to place them

in a separate schema of their own. Explicitly schema-qualified

references to the objects will therefore fail in either case.

<para>

Text search configuration information has been moved into core

system catalogs that are noticeably different from the tables used

or modified those tables will need adjustment.

</para>

</listitem>

catalogs using the new text search configuration SQL commands.

The replacement <literal>tsearch2</literal> module offers a little

bit of support for this by making it possible to load an old set

<productname>PostgreSQL</productname> 8.3. (Without the module,

it is not possible to load the configuration data because values in the

<type>regprocedure</> columns cannot be resolved to functions.)

<para>

The recommended way to update a pre-8.3 installation that uses

</para>

<procedure>

the replacement <literal>tsearch2</literal> module into each

database that will use text search. This must be done

<emphasis>before</> loading the dump data! If your old installation

than <literal>public</>, be sure to adjust the

<literal>tsearch2</literal> installation script so that the replacement

objects are created in that same schema.

<step>

<para>

Load the dump data. There will be quite a few errors reported

objects. These errors can be ignored, but this means you cannot

restore the dump in a single transaction (eg, you cannot use

<application>pg_restore</>'s <literal>-1</> switch).

<step>

<para>

configuration tables (<structname>pg_ts_cfg</> and so on), and

create equivalent built-in text search configurations as needed.

You may drop the old configuration tables once you've extracted

<para>

If you use this, you may also be interested in the <function>lo_manage</>

<function>lo_manage</> is useful to try

to avoid creating orphaned LOs in the first place.

</para>

file systems behave suboptimally when combined with battery-backup unit

(<acronym>BBU</>) disk controllers. In such setups, the synchronize

command forces all data from the controller cache to the disks,

if you are affected. If you are affected, the performance benefits

of the BBU can be regained by turning off write barriers in

the file system or reconfiguring the disk controller, if that is

the exception of <literal>fsync_writethrough</>, which can sometimes

force a flush of the disk cache even when other options do not do so.

However, it's quite platform-specific which one will be the fastest;

Note that this parameter is irrelevant if <varname>fsync</varname>

has been turned off.

</para>

</para>

<para>

</para>

</sect2>