rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/doc/src/sgml/ref/set_transaction.sgml

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

291 lines
11 KiB
Plaintext
Raw Normal View History

doc: make ref/*.sgml file header comment layout consistent
2020-05-15 14:52:24 +02:00
<!--
doc/src/sgml/ref/set_transaction.sgml
PostgreSQL documentation
-->
Convert SGML IDs to lower case IDs in SGML are case insensitive, and we have accumulated a mix of upper and lower case IDs, including different variants of the same ID. In XML, these will be case sensitive, so we need to fix up those differences. Going to all lower case seems most straightforward, and the current build process already makes all anchors and lower case anyway during the SGML->XML conversion, so this doesn't create any difference in the output right now. A future XML-only build process would, however, maintain any mixed case ID spellings in the output, so that is another reason to clean this up beforehand. Author: Alexander Lakhin <exclusion@gmail.com>
2017-10-20 03:16:39 +02:00
<refentry id="sql-set-transaction">
Add/edit index entries.
2003-08-31 19:32:24 +02:00
<indexterm zone="sql-set-transaction">
<primary>SET TRANSACTION</primary>
</indexterm>
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
<indexterm>
<primary>transaction isolation level</primary>
<secondary>setting</secondary>
</indexterm>
<indexterm>
<primary>read-only transaction</primary>
<secondary>setting</secondary>
</indexterm>
<indexterm>
<primary>deferrable transaction</primary>
<secondary>setting</secondary>
</indexterm>
doc: Improve DocBook XML validity DocBook XML is superficially compatible with DocBook SGML but has a slightly stricter DTD that we have been violating in a few cases. Although XSLT doesn't care whether the document is valid, the style sheets don't necessarily process invalid documents correctly, so we need to work toward fixing this. This first commit moves the indexterms in refentry elements to an allowed position. It has no impact on the output.
2014-02-24 03:25:35 +01:00
<refmeta>
<refentrytitle>SET TRANSACTION</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>SET TRANSACTION</refname>
<refpurpose>set the characteristics of the current transaction</refpurpose>
</refnamediv>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
<refsynopsisdiv>
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
<synopsis>
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
SET TRANSACTION <replaceable class="parameter">transaction_mode</replaceable> [, ...]
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
SET TRANSACTION SNAPSHOT <replaceable class="parameter">snapshot_id</replaceable>
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
SET SESSION CHARACTERISTICS AS TRANSACTION <replaceable class="parameter">transaction_mode</replaceable> [, ...]
Implement isolation levels read uncommitted and repeatable read as acting like the next higher one.
2003-11-06 23:08:15 +01:00
Easier to translate psql help Instead of requiring translators to translate the entire SQL command synopses, change create_help.pl to only require them to translate the placeholders, and paste those into the synopsis using a printf mechanism. Make some small updates to the markup to make it easier to parse. Note: This causes msgmerge of gettext 0.17 to segfault. You will need the patch from https://savannah.gnu.org/bugs/?27474 to make it work. msgmerge usually only runs on babel.postgresql.org, however.
2009-09-18 07:00:42 +02:00
<phrase>where <replaceable class="parameter">transaction_mode</replaceable> is one of:</phrase>
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED }
READ WRITE | READ ONLY
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
[ NOT ] DEFERRABLE
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
</synopsis>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
Minor documentation cleanup and improvement.
2004-09-20 02:04:19 +02:00
The <command>SET TRANSACTION</command> command sets the
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
characteristics of the current transaction. It has no effect on any
subsequent transactions. <command>SET SESSION
Read-only transactions, as defined in SQL.
2003-01-10 23:03:30 +01:00
CHARACTERISTICS</command> sets the default transaction
Minor editorializing.
2004-08-15 00:17:08 +02:00
characteristics for subsequent transactions of a session. These
Minor documentation cleanup and improvement.
2004-09-20 02:04:19 +02:00
defaults can be overridden by <command>SET TRANSACTION</command>
for an individual transaction.
Read-only transactions, as defined in SQL.
2003-01-10 23:03:30 +01:00
</para>
<para>
The available transaction characteristics are the transaction
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
isolation level, the transaction access mode (read/write or
read-only), and the deferrable mode.
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
In addition, a snapshot can be selected, though only for the current
transaction, not as a session default.
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</para>
<para>
The isolation level of a transaction determines what data the
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
transaction can see when other transactions are running concurrently:
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
<variablelist>
<varlistentry>
Fix markup.
2003-01-11 01:00:03 +01:00
<term><literal>READ COMMITTED</literal></term>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
<listitem>
<para>
A statement can only see rows committed before it began. This
is the default.
</para>
</listitem>
</varlistentry>
<varlistentry>
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
<term><literal>REPEATABLE READ</literal></term>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
<listitem>
<para>
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
All statements of the current transaction can only see rows committed
before the first query or data-modification statement was executed in
this transaction.
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</para>
</listitem>
</varlistentry>
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
<varlistentry>
<term><literal>SERIALIZABLE</literal></term>
<listitem>
<para>
All statements of the current transaction can only see rows committed
before the first query or data-modification statement was executed in
this transaction. If a pattern of reads and writes among concurrent
serializable transactions would create a situation which could not
have occurred for any serial (one-at-a-time) execution of those
transactions, one of them will be rolled back with a
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<literal>serialization_failure</literal> error.
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
</para>
</listitem>
</varlistentry>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</variablelist>
Read-only transactions, as defined in SQL.
2003-01-10 23:03:30 +01:00
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
The SQL standard defines one additional level, <literal>READ
UNCOMMITTED</literal>.
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
In <productname>PostgreSQL</productname> <literal>READ
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
UNCOMMITTED</literal> is treated as <literal>READ COMMITTED</literal>.
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
</para>
<para>
The transaction isolation level cannot be changed after the first query or
Implement isolation levels read uncommitted and repeatable read as acting like the next higher one.
2003-11-06 23:08:15 +01:00
data-modification statement (<command>SELECT</command>,
Read-only transactions, as defined in SQL.
2003-01-10 23:03:30 +01:00
<command>INSERT</command>, <command>DELETE</command>,
Doc: Miscellaneous doc updates for MERGE. Update a few places in the documentation that should mention MERGE among the list of applicable commands. In a couple of places, a slightly more detailed description of what happens for MERGE seems appropriate. Reviewed by Alvaro Herrera. Discussion: http://postgr.es/m/CAEZATCWqHLcxab89ATMQZNGFG_mxDPM%2BjzkSbXKD3JYPfRGvtw%40mail.gmail.com
2023-02-26 10:06:04 +01:00
<command>UPDATE</command>, <command>MERGE</command>,
<command>FETCH</command>, or
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
<command>COPY</command>) of a transaction has been executed. See
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="mvcc"/> for more information about transaction
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
isolation and concurrency control.
Read-only transactions, as defined in SQL.
2003-01-10 23:03:30 +01:00
</para>
<para>
The transaction access mode determines whether the transaction is
read/write or read-only. Read/write is the default. When a
transaction is read-only, the following SQL commands are
Doc: Miscellaneous doc updates for MERGE. Update a few places in the documentation that should mention MERGE among the list of applicable commands. In a couple of places, a slightly more detailed description of what happens for MERGE seems appropriate. Reviewed by Alvaro Herrera. Discussion: http://postgr.es/m/CAEZATCWqHLcxab89ATMQZNGFG_mxDPM%2BjzkSbXKD3JYPfRGvtw%40mail.gmail.com
2023-02-26 10:06:04 +01:00
disallowed: <command>INSERT</command>, <command>UPDATE</command>,
<command>DELETE</command>, <command>MERGE</command>, and
<command>COPY FROM</command> if the
Read-only transactions, as defined in SQL.
2003-01-10 23:03:30 +01:00
table they would write to is not a temporary table; all
<literal>CREATE</literal>, <literal>ALTER</literal>, and
<literal>DROP</literal> commands; <literal>COMMENT</literal>,
<literal>GRANT</literal>, <literal>REVOKE</literal>,
<literal>TRUNCATE</literal>; and <literal>EXPLAIN ANALYZE</literal>
and <literal>EXECUTE</literal> if the command they would execute is
among those listed. This is a high-level notion of read-only that
Minor editorializing.
2004-08-15 00:17:08 +02:00
does not prevent all writes to disk.
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</para>
Document the DEFERRABLE option in SET TRANSACTION command. Kevin Grittner
2011-03-07 09:42:49 +01:00
<para>
The <literal>DEFERRABLE</literal> transaction property has no effect
unless the transaction is also <literal>SERIALIZABLE</literal> and
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<literal>READ ONLY</literal>. When all three of these properties are
selected for a
Document the DEFERRABLE option in SET TRANSACTION command. Kevin Grittner
2011-03-07 09:42:49 +01:00
transaction, the transaction may block when first acquiring its snapshot,
after which it is able to run without the normal overhead of a
<literal>SERIALIZABLE</literal> transaction and without any risk of
Unify spelling of "canceled", "canceling", "cancellation" We had previously (af26857a2775e7ceb0916155e931008c2116632f) established the U.S. spellings as standard.
2011-06-29 08:26:14 +02:00
contributing to or being canceled by a serialization failure. This mode
Document the DEFERRABLE option in SET TRANSACTION command. Kevin Grittner
2011-03-07 09:42:49 +01:00
is well suited for long-running reports or backups.
</para>
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<para>
The <literal>SET TRANSACTION SNAPSHOT</literal> command allows a new
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
transaction to run with the same <firstterm>snapshot</firstterm> as an existing
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
transaction. The pre-existing transaction must have exported its snapshot
with the <literal>pg_export_snapshot</literal> function (see <xref
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
linkend="functions-snapshot-synchronization"/>). That function returns a
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
snapshot identifier, which must be given to <literal>SET TRANSACTION
SNAPSHOT</literal> to specify which snapshot is to be imported. The
identifier must be written as a string literal in this command, for example
docs: Fix snapshot name in SET TRANSACTION docs. Commit 6c2003f8a1 changed the snapshot names mentioned in SET TRANSACTION docs, however, there was one place that the commit missed updating the name. Back-patch to all supported versions. Author: Japin Li Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/MEYP282MB1669BD4280044501165F8B07B64F9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
2022-09-22 05:54:26 +02:00
<literal>'00000003-0000001B-1'</literal>.
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<literal>SET TRANSACTION SNAPSHOT</literal> can only be executed at the
start of a transaction, before the first query or
data-modification statement (<command>SELECT</command>,
<command>INSERT</command>, <command>DELETE</command>,
Doc: Miscellaneous doc updates for MERGE. Update a few places in the documentation that should mention MERGE among the list of applicable commands. In a couple of places, a slightly more detailed description of what happens for MERGE seems appropriate. Reviewed by Alvaro Herrera. Discussion: http://postgr.es/m/CAEZATCWqHLcxab89ATMQZNGFG_mxDPM%2BjzkSbXKD3JYPfRGvtw%40mail.gmail.com
2023-02-26 10:06:04 +01:00
<command>UPDATE</command>, <command>MERGE</command>,
<command>FETCH</command>, or
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<command>COPY</command>) of the transaction. Furthermore, the transaction
must already be set to <literal>SERIALIZABLE</literal> or
<literal>REPEATABLE READ</literal> isolation level (otherwise, the snapshot
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
would be discarded immediately, since <literal>READ COMMITTED</literal> mode takes
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
a new snapshot for each command). If the importing transaction uses
<literal>SERIALIZABLE</literal> isolation level, then the transaction that
exported the snapshot must also use that isolation level. Also, a
non-read-only serializable transaction cannot import a snapshot from a
read-only transaction.
</para>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</refsect1>
Allow default transaction isolation level (a.k.a. set session characteristics) to be set through GUC.
2001-07-01 00:03:26 +02:00
<refsect1>
<title>Notes</title>
<para>
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
If <command>SET TRANSACTION</command> is executed without a prior
Issue error on SET outside transaction block in some cases Issue error for SET LOCAL/CONSTRAINTS/TRANSACTION outside a transaction block, as they have no effect. Per suggestion from Morten Hustveit
2013-10-04 19:50:28 +02:00
<command>START TRANSACTION</command> or <command>BEGIN</command>,
doc: update wording of ineffective SET and ABORT commands Wording by Alvaro Herrera
2013-12-02 18:51:28 +01:00
it emits a warning and otherwise has no effect.
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
</para>
<para>
Fix misstatement in docs: CREATE TABLE AS is now part of the standard.
2004-09-27 01:48:07 +02:00
It is possible to dispense with <command>SET TRANSACTION</command>
by instead specifying the desired <replaceable
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
class="parameter">transaction_modes</replaceable> in
Fix misstatement in docs: CREATE TABLE AS is now part of the standard.
2004-09-27 01:48:07 +02:00
<command>BEGIN</command> or <command>START TRANSACTION</command>.
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
But that option is not available for <command>SET TRANSACTION
SNAPSHOT</command>.
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
</para>
<para>
Doc: document the current-transaction-modes GUCs. We had documentation of default_transaction_isolation et al, but for some reason not of transaction_isolation et al. AFAICS this is just an ancient oversight, so repair. Per bug #17077 from Yanliang Lei. Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org
2021-07-17 17:52:54 +02:00
The session default transaction modes can also be set or examined via the
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
configuration parameters <xref linkend="guc-default-transaction-isolation"/>,
<xref linkend="guc-default-transaction-read-only"/>, and
<xref linkend="guc-default-transaction-deferrable"/>.
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
(In fact <command>SET SESSION CHARACTERISTICS</command> is just a
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
verbose equivalent for setting these variables with <command>SET</command>.)
Minor editorializing.
2004-08-15 00:17:08 +02:00
This means the defaults can be set in the configuration file, via
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<command>ALTER DATABASE</command>, etc. Consult <xref linkend="runtime-config"/>
Minor editorializing.
2004-08-15 00:17:08 +02:00
for more information.
Allow default transaction isolation level (a.k.a. set session characteristics) to be set through GUC.
2001-07-01 00:03:26 +02:00
</para>
Doc: document the current-transaction-modes GUCs. We had documentation of default_transaction_isolation et al, but for some reason not of transaction_isolation et al. AFAICS this is just an ancient oversight, so repair. Per bug #17077 from Yanliang Lei. Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org
2021-07-17 17:52:54 +02:00
<para>
The current transaction's modes can similarly be set or examined via the
configuration parameters <xref linkend="guc-transaction-isolation"/>,
<xref linkend="guc-transaction-read-only"/>, and
<xref linkend="guc-transaction-deferrable"/>. Setting one of these
parameters acts the same as the corresponding <command>SET
TRANSACTION</command> option, with the same restrictions on when it can
be done. However, these parameters cannot be set in the configuration
file, or from any source other than live SQL.
</para>
Allow default transaction isolation level (a.k.a. set session characteristics) to be set through GUC.
2001-07-01 00:03:26 +02:00
</refsect1>
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<refsect1>
<title>Examples</title>
<para>
To begin a new transaction with the same snapshot as an already
existing transaction, first export the snapshot from the existing
transaction. That will return the snapshot identifier, for example:
<programlisting>
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT pg_export_snapshot();
pg_export_snapshot
Don't force-assign transaction id when exporting a snapshot. Previously we required every exported transaction to have an xid assigned. That was used to check that the exporting transaction is still running, which in turn is needed to guarantee that that necessary rows haven't been removed in between exporting and importing the snapshot. The exported xid caused unnecessary problems with logical decoding, because slot creation has to wait for all concurrent xid to finish, which in turn serializes concurrent slot creation. It also prohibited snapshots to be exported on hot-standby replicas. Instead export the virtual transactionid, which avoids the unnecessary serialization and the inability to export snapshots on standbys. This changes the file name of the exported snapshot, but since we never documented what that one means, that seems ok. Author: Petr Jelinek, slightly editorialized by me Reviewed-By: Andres Freund Discussion: https://postgr.es/m/f598b4b8-8cd7-0d54-0939-adda763d8c34@2ndquadrant.com
2017-06-14 20:57:21 +02:00
---------------------
00000003-0000001B-1
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
(1 row)
</programlisting>
Then give the snapshot identifier in a <command>SET TRANSACTION
SNAPSHOT</command> command at the beginning of the newly opened
transaction:
<programlisting>
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Don't force-assign transaction id when exporting a snapshot. Previously we required every exported transaction to have an xid assigned. That was used to check that the exporting transaction is still running, which in turn is needed to guarantee that that necessary rows haven't been removed in between exporting and importing the snapshot. The exported xid caused unnecessary problems with logical decoding, because slot creation has to wait for all concurrent xid to finish, which in turn serializes concurrent slot creation. It also prohibited snapshots to be exported on hot-standby replicas. Instead export the virtual transactionid, which avoids the unnecessary serialization and the inability to export snapshots on standbys. This changes the file name of the exported snapshot, but since we never documented what that one means, that seems ok. Author: Petr Jelinek, slightly editorialized by me Reviewed-By: Andres Freund Discussion: https://postgr.es/m/f598b4b8-8cd7-0d54-0939-adda763d8c34@2ndquadrant.com
2017-06-14 20:57:21 +02:00
SET TRANSACTION SNAPSHOT '00000003-0000001B-1';
Tweak markup to avoid extra whitespace in man pages
2012-03-28 19:37:19 +02:00
</programlisting></para>
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
</refsect1>
Convert SGML IDs to lower case IDs in SGML are case insensitive, and we have accumulated a mix of upper and lower case IDs, including different variants of the same ID. In XML, these will be case sensitive, so we need to fix up those differences. Going to all lower case seems most straightforward, and the current build process already makes all anchors and lower case anyway during the SGML->XML conversion, so this doesn't create any difference in the output right now. A future XML-only build process would, however, maintain any mixed case ID spellings in the output, so that is another reason to clean this up beforehand. Author: Alexander Lakhin <exclusion@gmail.com>
2017-10-20 03:16:39 +02:00
<refsect1 id="r1-sql-set-transaction-3">
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
<title>Compatibility</title>
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
<para>
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
These commands are defined in the <acronym>SQL</acronym> standard,
except for the <literal>DEFERRABLE</literal> transaction mode
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
and the <command>SET TRANSACTION SNAPSHOT</command> form, which are
Support synchronization of snapshots through an export/import procedure. A transaction can export a snapshot with pg_export_snapshot(), and then others can import it with SET TRANSACTION SNAPSHOT. The data does not leave the server so there are not security issues. A snapshot can only be imported while the exporting transaction is still running, and there are some other restrictions. I'm not totally convinced that we've covered all the bases for SSI (true serializable) mode, but it works fine for lesser isolation modes. Joachim Wieland, reviewed by Marko Tiikkaja, and rather heavily modified by Tom Lane
2011-10-23 00:22:45 +02:00
<productname>PostgreSQL</productname> extensions.
</para>
<para>
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
<literal>SERIALIZABLE</literal> is the default transaction
Minor editorializing.
2004-08-15 00:17:08 +02:00
isolation level in the standard. In
Implement isolation levels read uncommitted and repeatable read as acting like the next higher one.
2003-11-06 23:08:15 +01:00
<productname>PostgreSQL</productname> the default is ordinarily
<literal>READ COMMITTED</literal>, but you can change it as
Implement genuine serializable isolation level. Until now, our Serializable mode has in fact been what's called Snapshot Isolation, which allows some anomalies that could not occur in any serialized ordering of the transactions. This patch fixes that using a method called Serializable Snapshot Isolation, based on research papers by Michael J. Cahill (see README-SSI for full references). In Serializable Snapshot Isolation, transactions run like they do in Snapshot Isolation, but a predicate lock manager observes the reads and writes performed and aborts transactions if it detects that an anomaly might occur. This method produces some false positives, ie. it sometimes aborts transactions even though there is no anomaly. To track reads we implement predicate locking, see storage/lmgr/predicate.c. Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared memory is finite, so when a transaction takes many tuple-level locks on a page, the locks are promoted to a single page-level lock, and further to a single relation level lock if necessary. To lock key values with no matching tuple, a sequential scan always takes a relation-level lock, and an index scan acquires a page-level lock that covers the search key, whether or not there are any matching keys at the moment. A predicate lock doesn't conflict with any regular locks or with another predicate locks in the normal sense. They're only used by the predicate lock manager to detect the danger of anomalies. Only serializable transactions participate in predicate locking, so there should be no extra overhead for for other transactions. Predicate locks can't be released at commit, but must be remembered until all the transactions that overlapped with it have completed. That means that we need to remember an unbounded amount of predicate locks, so we apply a lossy but conservative method of tracking locks for committed transactions. If we run short of shared memory, we overflow to a new "pg_serial" SLRU pool. We don't currently allow Serializable transactions in Hot Standby mode. That would be hard, because even read-only transactions can cause anomalies that wouldn't otherwise occur. Serializable isolation mode now means the new fully serializable level. Repeatable Read gives you the old Snapshot Isolation level that we have always had. Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
mentioned above.
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
</para>
<para>
In the SQL standard, there is one other transaction characteristic
that can be set with these commands: the size of the diagnostics
Allow commas in BEGIN, START TRANSACTION, and SET TRANSACTION, as required by the SQL standard. For backwards compatibility, however, continue to accept the syntax without. Minor editorialization in the reference pages for these commands, too.
2004-08-12 23:00:34 +02:00
area. This concept is specific to embedded SQL, and therefore is
not implemented in the <productname>PostgreSQL</productname> server.
</para>
<para>
The SQL standard requires commas between successive <replaceable
class="parameter">transaction_modes</replaceable>, but for historical
reasons <productname>PostgreSQL</productname> allows the commas to be
omitted.
Last round of reference page editing.
2003-05-04 04:23:16 +02:00
</para>
Separated set constraints and set transaction reference pages, revised set reference page to new configuration system. Big update to administrator's guide, chapters Runtime environment, Client authentication, and User management, the latter two were part of the old Security chapter.
2000-06-18 23:24:54 +02:00
</refsect1>
</refentry>