</para>

<para>

Virtual ID of the transaction targeted by the lock,

or null if the target is not a virtual transaction ID

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

<xref linkend="transactions"/>

</para></entry>

</row>

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

</para>

<para>

ID of the transaction targeted by the lock,

or null if the targetis not a transaction ID

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

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

</para></entry>

</row>

</row>

<row>

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

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

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

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

<entry>no</entry>

</row>

<row>

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

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

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

<xref linkend="transaction-id"/></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.

monotonically and cannot be reused in the lifetime of a database

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

</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 backup-manifest SYSTEM "backup-manifest.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).

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.

</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.

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

details.

</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. 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; see <xref linkend="transaction-id"/> for details.

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.

subtransactions (subxids).

</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.

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

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

</para>

<para>

For more information, see

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

</para>

<para>

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

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

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

</para></entry>

</row>

</row>

<row>

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

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

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

<xref linkend="transaction-id"/>.</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</entry>

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

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

</row>

<row>

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

&brin;

&hash;

&storage;

&transaction;

&bki;

&planstats;

&backup-manifest;

<refnamediv>

<refname>RELEASE SAVEPOINT</refname>

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

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

</refnamediv>

<refsynopsisdiv>

<title>Description</title>

<para>

<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.

<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.

</para>

</refsect1>

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

<listitem>

<para>

The name of the savepoint todestroy.

The name of the savepoint torelease.

</para>

</listitem>

</varlistentry>

<para>

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

an aborted state.

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

</para>

<para>

<title>Examples</title>

<para>

To establish and laterdestroy a savepoint:

To establish and laterrelease 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 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.

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.

</para>

</listitem>

</varlistentry>

<para>

Roll back all commands that were executed after the savepoint was

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

again later, if needed.

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.

</para>

<para>

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

<para>

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

efficient, reliable operation.

This chapter explains how to control the reliability of

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

Write-Ahead Log.

</para>

<sect1 id="wal-reliability">

seem to be a problem in practice.

</para>

</sect1>

</chapter>