そこで、以下に関連する問題を検討しました。 絶縁について撤退しました。 低レベルでのデータの整理。 そして最後に、最も興味深い部分である文字列バージョンに到達しました。

タイトル

すでに述べたように、各行はデータベース内に複数のバージョンで同時に存在できます。 この目的のために、各バージョンには、このバージョンの動作の「時間」を決定する XNUMX つのマーク (xmin と xmax) が付いています。 引用符内 - 使用されるのは時間そのものではなく、特別な増加カウンターであるためです。 そして、このカウンターがトランザクション番号です。

(いつものように、現実はさらに複雑です。カウンタのビット容量が限られているため、トランザクション数は常に増加するわけではありません。ただし、これらの詳細については、フリーズするときに詳しく見ていきます。)

行が作成されると、xmin は INSERT コマンドを発行したトランザクション番号に設定され、xmax は空白のままになります。

行が削除されると、現在のバージョンの xmax 値に、DELETE を実行したトランザクションの番号がマークされます。

UPDATE コマンドによって行が変更されると、DELETE と INSERT という XNUMX つの操作が実際に実行されます。 行の現在のバージョンでは、xmax が UPDATE を実行したトランザクションの数に等しく設定されます。 次に、同じ文字列の新しいバージョンが作成されます。 その xmin 値は、以前のバージョンの xmax 値と一致します。

xmin フィールドと xmax フィールドは行バージョン ヘッダーに含まれます。 これらのフィールドに加えて、ヘッダーには次のような他のフィールドが含まれます。

• infomask は、このバージョンのプロパティを定義する一連のビットです。 それらはかなりたくさんあります。 主要なものについては徐々に検討していきます。
• ctid は、同じ行の次の新しいバージョンへのリンクです。 文字列の最新の最新バージョンの場合、ctid はこのバージョン自体を参照します。 数値の形式は (x,y) で、x はページ番号、y は配列内のインデックス番号です。
• null ビットマップ - null 値 (NULL) を含む特定のバージョンの列をマークします。 NULL は通常のデータ型値の XNUMX つではないため、属性は個別に保存する必要があります。

その結果、ヘッダーは非常に大きくなります。ラインのバージョンごとに少なくとも 23 バイト、通常は NULL ビットマップによりさらに大きくなります。 テーブルが「狭い」(つまり、列がほとんどない) 場合、有用な情報よりもオーバーヘッドが多くを占める可能性があります。

インサート

挿入から始めて、低レベルの文字列操作がどのように実行されるかを詳しく見てみましょう。

実験のために、XNUMX つの列とそのうちの XNUMX つにインデックスを含む新しいテーブルを作成してみましょう。

=> CREATE TABLE t(
  id serial,
  s text
);
=> CREATE INDEX ON t(s);

トランザクションを開始したら、XNUMX行を挿入しましょう。

=> BEGIN;
=> INSERT INTO t(s) VALUES ('FOO');

現在の取引番号は次のとおりです。

=> SELECT txid_current();

 txid_current 
--------------
         3664
(1 row)

ページの内容を見てみましょう。 pageinspect 拡張機能の heap_page_items 関数を使用すると、ポインターと行のバージョンに関する情報を取得できます。

=> SELECT * FROM heap_page_items(get_raw_page('t',0)) gx

-[ RECORD 1 ]-------------------
lp          | 1
lp_off      | 8160
lp_flags    | 1
lp_len      | 32
t_xmin      | 3664
t_xmax      | 0
t_field3    | 0
t_ctid      | (0,1)
t_infomask2 | 2
t_infomask  | 2050
t_hoff      | 24
t_bits      | 
t_oid       | 
t_data      | x0100000009464f4f

PostgreSQL のヒープという言葉はテーブルを指すことに注意してください。 これもこの用語の奇妙な使い方です - ヒープは知られています データ構造、テーブルと何の共通点もありません。 ここでこの言葉は、順序付けられたインデックスとは対照的に、「すべてが一緒に投げ込まれる」という意味で使用されます。

この関数は、理解しにくい形式でデータを「そのまま」表示します。 それを理解するために、情報の一部だけを残して解読します。

=> SELECT '(0,'||lp||')' AS ctid,
       CASE lp_flags
         WHEN 0 THEN 'unused'
         WHEN 1 THEN 'normal'
         WHEN 2 THEN 'redirect to '||lp_off
         WHEN 3 THEN 'dead'
       END AS state,
       t_xmin as xmin,
       t_xmax as xmax,
       (t_infomask & 256) > 0  AS xmin_commited,
       (t_infomask & 512) > 0  AS xmin_aborted,
       (t_infomask & 1024) > 0 AS xmax_commited,
       (t_infomask & 2048) > 0 AS xmax_aborted,
       t_ctid
FROM heap_page_items(get_raw_page('t',0)) gx

-[ RECORD 1 ]-+-------
ctid          | (0,1)
state         | normal
xmin          | 3664
xmax          | 0
xmin_commited | f
xmin_aborted  | f
xmax_commited | f
xmax_aborted  | t
t_ctid        | (0,1)

私たちがやったことは次のとおりです。

• インデックス番号にゼロを追加して、t_ctid: (ページ番号、インデックス番号) と同じに見えるようにしました。
• lp_flags ポインタの状態を解読しました。 ここでは「通常」です。これは、ポインタが実際に文字列のバージョンを参照していることを意味します。 他の意味については後ほど見ていきます。
• すべての情報ビットのうち、これまでに特定されたペアは XNUMX つだけです。 xmin_committed ビットと xmin_aborted ビットは、トランザクション番号 xmin がコミットされた (中止された) かどうかを示します。 XNUMX つの同様のビットはトランザクション番号 xmax を参照します。

何が見えますか？ 行を挿入すると、テーブル ページにインデックス番号 1 が表示され、行の最初で唯一のバージョンを指します。

文字列バージョンでは、xmin フィールドに現在のトランザクション番号が入力されます。 トランザクションはまだアクティブであるため、xmin_committed ビットと xmin_aborted ビットは両方とも設定されていません。

行バージョン ctid フィールドは同じ行を参照します。 これは、新しいバージョンが存在しないことを意味します。

このバージョンの行は削除されておらず最新であるため、xmax フィールドにはダミーの数値 0 が入力されます。 xmax_aborted ビットが設定されているため、トランザクションはこの数値に注意を払いません。

トランザクション番号に情報ビットを追加して、可読性を向上させるためにもう一歩進めてみましょう。 リクエストは複数回必要になるため、関数を作成しましょう。

=> CREATE FUNCTION heap_page(relname text, pageno integer)
RETURNS TABLE(ctid tid, state text, xmin text, xmax text, t_ctid tid)
AS $$
SELECT (pageno,lp)::text::tid AS ctid,
       CASE lp_flags
         WHEN 0 THEN 'unused'
         WHEN 1 THEN 'normal'
         WHEN 2 THEN 'redirect to '||lp_off
         WHEN 3 THEN 'dead'
       END AS state,
       t_xmin || CASE
         WHEN (t_infomask & 256) > 0 THEN ' (c)'
         WHEN (t_infomask & 512) > 0 THEN ' (a)'
         ELSE ''
       END AS xmin,
       t_xmax || CASE
         WHEN (t_infomask & 1024) > 0 THEN ' (c)'
         WHEN (t_infomask & 2048) > 0 THEN ' (a)'
         ELSE ''
       END AS xmax,
       t_ctid
FROM heap_page_items(get_raw_page(relname,pageno))
ORDER BY lp;
$$ LANGUAGE SQL;

この形式では、行バージョンのヘッダーで何が起こっているかがより明確になります。

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3664 | 0 (a) | (0,1)
(1 row)

同様ではありますが、詳細度は大幅に劣りますが、疑似列 xmin および xmax を使用してテーブル自体から情報を取得できます。

=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3664 |    0 |  1 | FOO
(1 row)

固定

トランザクションが正常に完了した場合は、そのステータスを覚えておく必要があります。トランザクションがコミットされていることに注意してください。 これを行うには、XACT と呼ばれる構造が使用されます (バージョン 10 より前では、CLOG (コミット ログ) と呼ばれていました。この名前は今でもさまざまな場所で見つけることができます)。

XACT はシステム カタログ テーブルではありません。 これらは PGDATA/pg_xact ディレクトリ内のファイルです。 行バージョン ヘッダーと同様に、トランザクションごとにコミットと中止の XNUMX つのビットがあります。 この情報は便宜上複数のファイルに分割されていますが、凍結を検討する際にこの問題に戻ります。 これらのファイルの操作は、他のファイルと同様にページごとに実行されます。

したがって、XACT でトランザクションがコミットされると、このトランザクションに対してコミットされたビットが設定されます。 コミット中に起こることはこれだけです (ただし、録画前のログについてはまだ話していません)。

別のトランザクションが先ほど確認したテーブル ページにアクセスすると、いくつかの質問に答える必要があります。

1. xminトランザクションは完了しましたか? そうでない場合、文字列の作成されたバージョンは表示されないはずです。
   このチェックは、インスタンスの共有メモリにある ProcArray と呼ばれる別の構造を調べることによって実行されます。 これには、すべてのアクティブなプロセスのリストが含まれており、それぞれの現在の (アクティブな) トランザクションの番号が示されます。
2. 完了した場合、どのようにしてコミットまたはキャンセルするのでしょうか? キャンセルすると、行バージョンも表示されなくなります。
   これがまさに XACT の目的です。 ただし、XACT の最後のページは RAM のバッファに保存されますが、XACT を毎回チェックするのは依然としてコストがかかります。 したがって、トランザクション ステータスが決定されると、文字列バージョンの xmin_committed ビットと xmin_aborted ビットに書き込まれます。 これらのビットのいずれかが設定されている場合、トランザクション xmin の状態は既知であるとみなされ、次のトランザクションは XACT にアクセスする必要がなくなります。

これらのビットが挿入を行うトランザクション自体によって設定されないのはなぜですか? 挿入が発生したとき、トランザクションはそれが成功するかどうかをまだ知りません。 そして、コミットの時点では、どのページのどの行が変更されたのかはもはや明確ではありません。 このようなページはたくさんある可能性があり、それらを暗記することは有益ではありません。 さらに、一部のページはバッファ キャッシュからディスクに追い出される可能性があります。 ビットを変更するためにそれらを再度読み取ると、コミットが大幅に遅くなります。

節約の欠点は、変更後、あらゆるトランザクション (単純な読み取り - SELECT を実行するトランザクションであっても) がバッファー キャッシュ内のデータ ページを変更し始める可能性があることです。

それでは、変更を修正しましょう。

=> COMMIT;

ページには何も変化がありません (ただし、トランザクション ステータスがすでに XACT に記録されていることがわかります)。

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3664 | 0 (a) | (0,1)
(1 row)

ここで、最初にページにアクセスするトランザクションは、xmin トランザクション ステータスを決定し、それを情報ビットに書き込む必要があります。

=> SELECT * FROM t;

 id |  s  
----+-----
  1 | FOO
(1 row)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 0 (a) | (0,1)
(1 row)

削除

行が削除されると、現在の削除トランザクションの番号が現在のバージョンの xmax フィールドに書き込まれ、xmax_aborted ビットがクリアされます。

アクティブなトランザクションに対応する xmax の設定値が行ロックとして機能することに注意してください。 別のトランザクションがこの行を更新または削除したい場合、トランザクション xmax が完了するまで待機する必要があります。 ブロックについては後ほど詳しく説明します。 現時点では、行ロックの数が無制限であることに注意してください。 これらは RAM のスペースを占有せず、その数によってシステムのパフォーマンスが低下することはありません。 確かに、「長い」トランザクションには他にも欠点がありますが、それについては後ほど説明します。

行を削除しましょう。

=> BEGIN;
=> DELETE FROM t;
=> SELECT txid_current();

 txid_current 
--------------
         3665
(1 row)

トランザクション番号が xmax フィールドに書き込まれていますが、情報ビットが設定されていないことがわかります。

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normal | 3664 (c) | 3665 | (0,1)
(1 row)

キャンセル

変更の中止はコミットと同様に機能しますが、XACT でのみ、中止されたビットがトランザクションに設定されます。 元に戻すのはコミットするのと同じくらい簡単です。 このコマンドは ROLLBACK と呼ばれますが、変更はロールバックされません。トランザクションによってデータ ページ内で変更された内容はすべて変更されません。

=> ROLLBACK;
=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normal | 3664 (c) | 3665 | (0,1)
(1 row)

ページがアクセスされると、ステータスがチェックされ、xmax_aborted ヒント ビットが行バージョンに設定されます。 xmax 番号自体はページ上に残りますが、誰もそれを見ません。

=> SELECT * FROM t;

 id |  s  
----+-----
  1 | FOO
(1 row)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   |   xmax   | t_ctid 
-------+--------+----------+----------+--------
 (0,1) | normal | 3664 (c) | 3665 (a) | (0,1)
(1 row)

アップデート

更新は、最初に行の現在のバージョンを削除してから新しいバージョンを挿入したかのように機能します。

=> BEGIN;
=> UPDATE t SET s = 'BAR';
=> SELECT txid_current();

 txid_current 
--------------
         3666
(1 row)

クエリにより次の XNUMX 行が生成されます (新しいバージョン)。

=> SELECT * FROM t;

 id |  s  
----+-----
  1 | BAR
(1 row)

ただし、ページには両方のバージョンが表示されます。

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 3666  | (0,2)
 (0,2) | normal | 3666     | 0 (a) | (0,2)
(2 rows)

削除されたバージョンには、xmax フィールドの現在のトランザクション番号がマークされます。 さらに、前のトランザクションがキャンセルされたため、この値は古い値に上書きされます。 また、現在のトランザクションのステータスがまだ不明であるため、xmax_aborted ビットはクリアされます。

行の最初のバージョンは、XNUMX 番目 (t_ctid フィールド) を新しいバージョンとして参照するようになりました。

XNUMX 番目のインデックスはインデックス ページに表示され、XNUMX 番目の行はテーブル ページの XNUMX 番目のバージョンを参照します。

削除の場合と同様に、行の最初のバージョンの xmax 値は、行がロックされていることを示します。

さて、取引を完了しましょう。

=> COMMIT;

索引

これまではテーブル ページについてのみ説明してきました。 インデックスの内部では何が起こっているのでしょうか?

インデックス ページの情報は、インデックスの特定の種類によって大きく異なります。 また、同じ種類のインデックスでも、さまざまな種類のページがあります。 たとえば、B ツリーにはメタデータ ページと「通常の」ページがあります。

ただし、ページには通常、行へのポインターの配列と行自体が含まれます (表ページと同様)。 さらに、ページの最後には特別なデータ用のスペースがあります。

インデックス内の行は、インデックスの種類に応じて非常に異なる構造を持つこともあります。 たとえば、B ツリーの場合、リーフ ページに関連する行には、インデックス キー値と、対応するテーブル行への参照 (ctid) が含まれます。 一般に、インデックスはまったく異なる方法で構造化できます。

最も重要な点は、どのタイプのインデックスにも行バージョンが存在しないということです。 あるいは、各行が正確に XNUMX つのバージョンで表されると仮定することもできます。 つまり、インデックス行ヘッダーには xmin フィールドと xmax フィールドがありません。 インデックスからのリンクは行のすべてのテーブル バージョンにつながると想定できます。そのため、テーブルを見るだけでトランザクションがどのバージョンを参照するかを把握できます。 (いつものように、これがすべての真実ではありません。場合によっては、可視性マップによってプロセスを最適化できますが、これについては後で詳しく説明します。)

同時に、インデックス ページでは、現在のバージョンと古いバージョンの両方のバージョンへのポインターが見つかります。

=> SELECT itemoffset, ctid FROM bt_page_items('t_s_idx',1);

 itemoffset | ctid  
------------+-------
          1 | (0,2)
          2 | (0,1)
(2 rows)

仮想トランザクション

実際には、PostgreSQL はトランザクション数を「保存」できる最適化を使用します。

トランザクションがデータを読み取るだけの場合、行バージョンの可視性には影響しません。 したがって、サービス プロセスは最初にトランザクションに仮想 xid を発行します。 この番号はプロセス ID とシーケンス番号で構成されます。

この番号の発行にはすべてのプロセス間の同期が必要ないため、非常に高速です。 フリーズについて話すときに、仮想番号を使用する別の理由について説明します。

仮想番号はデータ スナップショットではまったく考慮されません。

さまざまな時点で、すでに使用されている番号を持つ仮想トランザクションがシステム内に存在する可能性がありますが、これは正常な現象です。 ただし、そのような数値をデータ ページに書き込むことはできません。次回そのページにアクセスすると、すべての意味が失われる可能性があるからです。

=> BEGIN;
=> SELECT txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                         
(1 row)

トランザクションがデータの変更を開始すると、実際の一意のトランザクション番号が与えられます。

=> UPDATE accounts SET amount = amount - 1.00;
=> SELECT txid_current_if_assigned();

 txid_current_if_assigned 
--------------------------
                     3667
(1 row)

=> COMMIT;

ネストされたトランザクション

ポイントを貯める

SQLで定義 セーブポイント (セーブポイント) を使用すると、トランザクションを完全に中断することなく、トランザクションの一部をキャンセルできます。 しかし、トランザクションはすべての変更に対して同じステータスを持ち、物理的にデータはロールバックされないため、これは上の図には当てはまりません。

この機能を実装するには、セーブポイントのあるトランザクションをいくつかの個別のトランザクションに分割します。 ネストされたトランザクション （サブトランザクション）のステータスを個別に管理できます。

ネストされたトランザクションには、独自の番号 (メイン トランザクションの番号よりも大きい番号) が付いています。 ネストされたトランザクションのステータスは XACT に通常の方法で記録されますが、最終的なステータスはメイン トランザクションのステータスによって異なります。メイン トランザクションがキャンセルされると、ネストされたトランザクションもすべてキャンセルされます。

トランザクションのネストに関する情報は、PGDATA/pg_subtrans ディレクトリ内のファイルに保存されます。 ファイルは、XACT バッファと同じ方法で編成されたインスタンスの共有メモリ内のバッファを介してアクセスされます。

ネストされたトランザクションと自律型トランザクションを混同しないでください。 自律型トランザクションは互いに依存しませんが、ネストされたトランザクションは依存します。 通常の PostgreSQL には自律型トランザクションはありません。おそらく最良のことでしょう。自律型トランザクションが必要になることは非常に稀ですが、他の DBMS に存在することで悪用が引き起こされ、誰もがその被害に遭うことになります。

テーブルをクリアし、トランザクションを開始して行を挿入しましょう。

=> TRUNCATE TABLE t;
=> BEGIN;
=> INSERT INTO t(s) VALUES ('FOO');
=> SELECT txid_current();

 txid_current 
--------------
         3669
(1 row)

=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
(1 row)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
(1 row)

次に、セーブポイントを配置し、別の行を挿入しましょう。

=> SAVEPOINT sp;
=> INSERT INTO t(s) VALUES ('XYZ');
=> SELECT txid_current();

 txid_current 
--------------
         3669
(1 row)

txid_current() 関数は、ネストされたトランザクション番号ではなく、メイン トランザクション番号を返すことに注意してください。

=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3670 |    0 |  3 | XYZ
(2 rows)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
 (0,2) | normal | 3670 | 0 (a) | (0,2)
(2 rows)

保存ポイントまでロールバックして XNUMX 行目を挿入しましょう。

=> ROLLBACK TO sp;
=> INSERT INTO t(s) VALUES ('BAR');
=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3671 |    0 |  4 | BAR
(2 rows)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669     | 0 (a) | (0,1)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671     | 0 (a) | (0,3)
(3 rows)

ページには、キャンセルされたネストされたトランザクションによって追加された行が引き続き表示されます。

変更を修正します。

=> COMMIT;
=> SELECT xmin, xmax, * FROM t;

 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3671 |    0 |  4 | BAR
(2 rows)

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669 (c) | 0 (a) | (0,1)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671 (c) | 0 (a) | (0,3)
(3 rows)

これで、ネストされた各トランザクションが独自のステータスを持っていることが明確にわかります。

ネストされたトランザクションは SQL で明示的に使用できないことに注意してください。つまり、現在のトランザクションを完了せずに新しいトランザクションを開始することはできません。 このメカニズムは、セーブポイントを使用するとき、PL/pgSQL 例外を処理するとき、および他の多くのより特殊なケースで暗黙的にアクティブ化されます。

=> BEGIN;

BEGIN

=> BEGIN;

WARNING:  there is already a transaction in progress
BEGIN

=> COMMIT;

COMMIT

=> COMMIT;

WARNING:  there is no transaction in progress
COMMIT

エラーと操作の原子性

操作の実行中にエラーが発生した場合はどうなりますか? たとえば、次のようになります。

=> BEGIN;
=> SELECT * FROM t;

 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rows)

=> UPDATE t SET s = repeat('X', 1/(id-4));

ERROR:  division by zero

エラーが発生しました。 これで、トランザクションは中止されたとみなされ、トランザクション内での操作は許可されなくなります。

=> SELECT * FROM t;

ERROR:  current transaction is aborted, commands ignored until end of transaction block

変更をコミットしようとしても、PostgreSQL は中止を報告します。

=> COMMIT;

ROLLBACK

障害が発生するとトランザクションを続行できないのはなぜですか? 実際には、変更の一部にアクセスできるような方法でエラーが発生する可能性があります。つまり、トランザクションではなく、オペレーターのアトミック性に違反することになります。 この例のように、オペレーターはエラーの XNUMX 行前を更新できました。

=> SELECT * FROM heap_page('t',0);

 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669 (c) | 3672  | (0,4)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671 (c) | 0 (a) | (0,3)
 (0,4) | normal | 3672     | 0 (a) | (0,4)
(4 rows)

psql には、失敗したオペレーターのアクションがロールバックされたかのようにトランザクションを継続できるモードがあると言わなければなりません。

=> set ON_ERROR_ROLLBACK on
=> BEGIN;
=> SELECT * FROM t;

 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rows)

=> UPDATE t SET s = repeat('X', 1/(id-4));

ERROR:  division by zero

=> SELECT * FROM t;

 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rows)

=> COMMIT;

このモードでは、psql が実際に各コマンドの前に暗黙的なセーブ ポイントを配置し、失敗した場合にはそこへのロールバックを開始することは推測に難しくありません。 セーブポイントの設定 (セーブポイントにロールバックしない場合でも) には多大なオーバーヘッドが伴うため、このモードはデフォルトでは使用されません。

続きます。

出所： habr.com