</row>

<row>

<entry><literal>%v</literal></entry>

<entry>Virtual transaction ID (backendID/localXID); see

<xref linkend="transaction-id"/></entry>

<entry>Virtual transaction ID (backendID/localXID)</entry>

<entry>no</entry>

</row>

<row>

<entry><literal>%x</literal></entry>

<entry>Transaction ID (0 if none is assigned); see

<xref linkend="transaction-id"/></entry>

<entry>Transaction ID (0 if none is assigned)</entry>

<entry>no</entry>

</row>

<row>

<structfield>xmin</structfield> and <structfield>xmax</structfield>. Transaction identifiers are 32-bit quantities.

In some contexts, a 64-bit variant <type>xid8</type> is used. Unlike

<type>xid</type> values, <type>xid8</type> values increase strictly

monotonically and cannot be reused in the lifetime of a database

cluster. See <xref linkend="transaction-id"/> for more details.

monotonically and cannot be reused in the lifetime of a database cluster.

</para>

<para>

<!ENTITY protocol SYSTEM "protocol.sgml">

<!ENTITY sources SYSTEM "sources.sgml">

<!ENTITY storage SYSTEM "storage.sgml">

<!ENTITY transaction SYSTEM "xact.sgml">

<!ENTITY tablesample-method SYSTEM "tablesample-method.sgml">

<!ENTITY generic-wal SYSTEM "generic-wal.sgml">

<!ENTITY custom-rmgr SYSTEM "custom-rmgr.sgml">

<para>

Returns the current transaction's ID. It will assign a new one if the

current transaction does not have one already (because it has not

performed any database updates); see <xref

linkend="transaction-id"/> for details. If executed in a

subtransaction, this will return the top-level transaction ID;

see <xref linkend="subxacts"/> for details.

performed any database updates).

</para></entry>

</row>

ID is assigned yet. (It's best to use this variant if the transaction

might otherwise be read-only, to avoid unnecessary consumption of an

XID.)

If executed in a subtransaction, this will return the top-level

transaction ID.

</para></entry>

</row>

<para>

Returns a current <firstterm>snapshot</firstterm>, a data structure

showing which transaction IDs are now in-progress.

Only top-level transaction IDs are included in the snapshot;

subtransaction IDs are not shown; see <xref linkend="subxacts"/>

for details.

</para></entry>

</row>

Is the given transaction ID <firstterm>visible</firstterm> according

to this snapshot (that is, was it completed before the snapshot was

taken)? Note that this function will not give the correct answer for

a subtransaction ID (subxid); see <xref linkend="subxacts"/> for

details.

a subtransaction ID.

</para></entry>

</row>

</tbody>

wraps around every 4 billion transactions. However,

the functions shown in <xref linkend="functions-pg-snapshot"/> use a

64-bit type <type>xid8</type> that does not wrap around during the life

of an installation and can be converted to <type>xid</type> by casting if

required; see <xref linkend="transaction-id"/> for details.

The data type <type>pg_snapshot</type> stores information about

of an installation, and can be converted to <type>xid</type> by casting if

required. The data type <type>pg_snapshot</type> stores information about

transaction ID visibility at a particular moment in time. Its components

are described in <xref linkend="functions-pg-snapshot-parts"/>.

<type>pg_snapshot</type>'s textual representation is

xmax</literal> and not in this list was already completed at the time

of the snapshot, and thus is either visible or dead according to its

commit status. This list does not include the transaction IDs of

subtransactions (subxids).

subtransactions.

</entry>

</row>

</tbody>

<literal>3</literal> (values under that are reserved) and the

epoch value is incremented by one.

In some contexts, the epoch and xid values are

considered together as a single 64-bit value; see <xref

linkend="transaction-id"/> for more details.

considered together as a single 64-bit value.

</para>

<para>

For more information, see

<structfield>backend_xid</structfield> <type>xid</type>

</para>

<para>

Top-level transaction identifier of this backend, if any; see

<xref linkend="transaction-id"/>.

Top-level transaction identifier of this backend, if any.

</para></entry>

</row>

</row>

<row>

<entry><literal>virtualxid</literal></entry>

<entry>Waiting to acquire a virtual transaction ID lock; see

<xref linkend="transaction-id"/>.</entry>

<entry>Waiting to acquire a virtual transaction ID lock.</entry>

</row>

</tbody>

</tgroup>

<row>

<entry><structfield>locker</structfield></entry>

<entry><type>xid</type></entry>

<entry>Transaction ID of locker, or multixact ID if

multitransaction; see <xref linkend="transaction-id"/></entry>

<entry>Transaction ID of locker, or multixact ID if multitransaction</entry>

</row>

<row>

<entry><structfield>multi</structfield></entry>

&brin;

&hash;

&storage;

&transaction;

&bki;

&planstats;

&backup-manifest;

<refnamediv>

<refname>RELEASE SAVEPOINT</refname>

<refpurpose>release a previously defined savepoint</refpurpose>

<refpurpose>destroy a previously defined savepoint</refpurpose>

</refnamediv>

<refsynopsisdiv>

<title>Description</title>

<para>

<command>RELEASE SAVEPOINT</command> releases the named savepoint and

all active savepoints that were created after the named savepoint,

and frees their resources. All changes made since the creation of

the savepoint that didn't already get rolled back are merged into

the transaction or savepoint that was active when the named savepoint

was created. Changes made after <command>RELEASE SAVEPOINT</command>

will also be part of this active transaction or savepoint.

<command>RELEASE SAVEPOINT</command> destroys a savepoint previously defined

in the current transaction.

</para>

<para>

Destroying a savepoint makes it unavailable as a rollback point,

but it has no other user visible behavior. It does not undo the

effects of commands executed after the savepoint was established.

(To do that, see <xref linkend="sql-rollback-to"/>.)

Destroying a savepoint when

it is no longer needed allows the system to reclaim some resources

earlier than transaction end.

</para>

<para>

<command>RELEASE SAVEPOINT</command> also destroys all savepoints that were

established after the named savepoint was established.

</para>

</refsect1>

<term><replaceable>savepoint_name</replaceable></term>

<listitem>

<para>

The name of the savepoint torelease.

The name of the savepoint todestroy.

</para>

</listitem>

</varlistentry>

<para>

It is not possible to release a savepoint when the transaction is in

an aborted state; to do that, use <xref linkend="sql-rollback-to"/>.

an aborted state.

</para>

<para>

<title>Examples</title>

<para>

To establish and laterrelease a savepoint:

To establish and laterdestroy a savepoint:

<programlisting>

BEGIN;

INSERT INTO table1 VALUES (3);

</programlisting>

The above transaction will insert both 3 and 4.

</para>

<para>

A more complex example with multiple nested subtransactions:

<programlisting>

BEGIN;

INSERT INTO table1 VALUES (1);

SAVEPOINT sp1;

INSERT INTO table1 VALUES (2);

SAVEPOINT sp2;

INSERT INTO table1 VALUES (3);

RELEASE SAVEPOINT sp2;

INSERT INTO table1 VALUES (4))); -- generates an error

</programlisting>

In this example, the application requests the release of the savepoint

<literal>sp2</literal>, which inserted 3. This changes the insert's

transaction context to <literal>sp1</literal>. When the statement

attempting to insert value 4 generates an error, the insertion of 2 and

4 are lost because they are in the same, now-rolled back savepoint,

and value 3 is in the same transaction context. The application can

now only choose one of these two commands, since all other commands

will be ignored:

<programlisting>

ROLLBACK;

ROLLBACK TO SAVEPOINT sp1;

</programlisting>

Choosing <command>ROLLBACK</command> will abort everything, including

value 1, whereas <command>ROLLBACK TO SAVEPOINT sp1</command> will retain

value 1 and allow the transaction to continue.

</para>

</refsect1>

<refsect1>

<term><literal>AND CHAIN</literal></term>

<listitem>

<para>

If <literal>AND CHAIN</literal> is specified, a new(not aborted)

transaction isimmediately started with the same transaction

characteristics (see <xreflinkend="sql-set-transaction"/>) as the

just finished one. Otherwise,no new transaction is started.

If <literal>AND CHAIN</literal> is specified, a newtransaction is

immediately started with the same transaction characteristics (see <xref

linkend="sql-set-transaction"/>) as the just finished one. Otherwise,

no new transaction is started.

</para>

</listitem>

</varlistentry>

<para>

Roll back all commands that were executed after the savepoint was

established and then start a new subtransaction at the same transaction level.

The savepoint remains valid and can be rolled back to again later,

if needed.

established. The savepoint remains valid and can be rolled back to

again later, if needed.

</para>

<para>

</para>

<para>

Virtual ID of the transaction targeted by the lock,

or null if the target is not a virtual transaction ID; see

<xref linkend="transactions"/>

or null if the target is not a virtual transaction ID

</para></entry>

</row>

<structfield>transactionid</structfield> <type>xid</type>

</para>

<para>

ID of the transaction targeted by the lock, or null if the target

is not a transaction ID; <xref linkend="transactions"/>

ID of the transaction targeted by the lock,

or null if the targetis not a transaction ID

</para></entry>

</row>

<title>Reliability and the Write-Ahead Log</title>

<para>

This chapter explains how to control the reliability of

<productname>PostgreSQL</productname>, including details about the

Write-Ahead Log.

This chapter explains how the Write-Ahead Log is used to obtain

efficient, reliable operation.

</para>

<sect1 id="wal-reliability">

seem to be a problem in practice.

</para>

</sect1>

</chapter>