그래서 우리는 관련된 문제를 고려했습니다. 단열재, 그리고 약 퇴각했습니다 낮은 수준에서 데이터 정리. 그리고 마지막으로 가장 흥미로운 부분인 문자열 버전에 도달했습니다.

이름

이미 말했듯이 각 행은 데이터베이스의 여러 버전에 동시에 존재할 수 있습니다. 한 버전은 어떻게든 다른 버전과 구별되어야 합니다. 이를 위해 각 버전에는 해당 버전의 작업 "시간"을 결정하는 두 개의 표시(xmin 및 xmax)가 있습니다. 따옴표로 묶음 - 사용되는 것은 시간이 아니라 특별한 증가 카운터이기 때문입니다. 그리고 이 카운터가 거래번호입니다.

(평상시와 마찬가지로 현실은 더 복잡합니다. 카운터의 제한된 비트 용량으로 인해 거래 수를 항상 늘릴 수는 없습니다. 하지만 이러한 세부 사항은 동결되면 자세히 살펴보겠습니다.)

행이 생성되면 xmin은 INSERT 명령을 실행한 트랜잭션 번호로 설정되고 xmax는 공백으로 남습니다.

행이 삭제되면 현재 버전의 xmax 값에 DELETE를 수행한 트랜잭션 번호가 표시됩니다.

UPDATE 명령으로 행이 수정되면 실제로 DELETE 및 INSERT라는 두 가지 작업이 수행됩니다. 행의 현재 버전은 xmax를 UPDATE를 수행한 트랜잭션 수와 동일하게 설정합니다. 그런 다음 동일한 문자열의 새 버전이 생성됩니다. xmin 값은 이전 버전의 xmax 값과 일치합니다.

xmin 및 xmax 필드는 행 버전 헤더에 포함됩니다. 헤더에는 이러한 필드 외에도 다음과 같은 다른 필드가 포함됩니다.

• infomask는 이 버전의 속성을 정의하는 일련의 비트입니다. 꽤 많이 있습니다. 우리는 점차적으로 주요 것들을 고려할 것입니다.
• ctid는 동일한 줄의 다음 최신 버전에 대한 링크입니다. 최신 문자열 버전의 경우 ctid는 이 버전 자체를 나타냅니다. 숫자의 형식은 (x,y)입니다. 여기서 x는 페이지 번호이고 y는 배열의 인덱스 번호입니다.
• null 비트맵 - null 값(NULL)을 포함하는 지정된 버전의 열을 표시합니다. NULL은 일반 데이터형 값이 아니므로 속성을 별도로 저장해야 한다.

결과적으로 헤더는 상당히 큽니다. 각 라인 버전에 대해 최소 23바이트이며 일반적으로 NULL 비트맵으로 인해 그 이상입니다. 테이블이 "좁은" 경우(즉, 열이 거의 포함되지 않은 경우) 오버헤드가 유용한 정보보다 더 많이 차지할 수 있습니다.

삽입

삽입부터 시작하여 하위 수준 문자열 연산이 수행되는 방식을 자세히 살펴보겠습니다.

실험을 위해 두 개의 열과 그 중 하나에 인덱스가 있는 새 테이블을 만들어 보겠습니다.

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

트랜잭션을 시작한 후 하나의 행을 삽입해 보겠습니다.

=> 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: (페이지 번호, 색인 번호)와 동일하게 보이도록 색인 번호에 XNUMX을 추가했습니다.
• lp_flags 포인터의 상태를 해독했습니다. 여기서는 "정상"입니다. 이는 포인터가 실제로 문자열 버전을 참조한다는 의미입니다. 나중에 다른 의미를 살펴보겠습니다.
• 모든 정보 비트 중에서 지금까지 두 쌍만 식별되었습니다. xmin_committed 및 xmin_aborted 비트는 트랜잭션 번호 xmin이 커밋(중단)되었는지 여부를 나타냅니다. 두 개의 유사한 비트는 트랜잭션 번호 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 디렉터리에 있는 파일입니다. 행 버전 헤더와 마찬가지로 각 트랜잭션에 대해 커밋 및 중단이라는 두 비트가 있습니다. 이 정보는 편의상 여러 파일로 나누어져 있으며, 동결을 고려할 때 이 문제에 대해 다시 언급하겠습니다. 그리고 이러한 파일 작업은 다른 모든 파일과 마찬가지로 페이지별로 수행됩니다.

따라서 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)

쿼리는 한 줄(새 버전)을 생성합니다.

=> 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 비트는 현재 트랜잭션의 상태가 아직 알려지지 않았기 때문에 지워집니다.

이제 행의 첫 번째 버전은 두 번째(t_ctid 필드)를 최신 버전으로 참조합니다.

두 번째 인덱스는 인덱스 페이지에 나타나고 두 번째 행은 테이블 페이지의 두 번째 버전을 참조합니다.

삭제와 마찬가지로 행의 첫 번째 버전에 있는 xmax 값은 행이 잠겨 있음을 나타냅니다.

자, 거래를 완료하겠습니다.

=> COMMIT;

지수

지금까지 우리는 테이블 페이지에 대해서만 이야기했습니다. 인덱스 내부에서는 어떤 일이 발생하나요?

인덱스 페이지의 정보는 특정 인덱스 유형에 따라 크게 달라집니다. 그리고 한 유형의 인덱스라도 다양한 유형의 페이지가 있습니다. 예를 들어 B-트리에는 메타데이터 페이지와 "일반" 페이지가 있습니다.

그러나 페이지에는 일반적으로 행과 행 자체에 대한 포인터 배열이 있습니다(테이블 페이지와 마찬가지로). 또한 페이지 끝에는 특별한 데이터를 위한 공간이 있습니다.

인덱스의 행은 인덱스 유형에 따라 매우 다른 구조를 가질 수도 있습니다. 예를 들어 B-트리의 경우 리프 페이지와 관련된 행에는 인덱싱 키 값과 해당 테이블 행에 대한 참조(ctid)가 포함됩니다. 일반적으로 인덱스는 완전히 다른 방식으로 구성될 수 있습니다.

가장 중요한 점은 모든 유형의 인덱스에 행 버전이 없다는 것입니다. 글쎄, 아니면 각 줄이 정확히 하나의 버전으로 표현된다고 가정할 수 있습니다. 즉, 인덱스 행 헤더에는 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)

저장 지점으로 롤백하고 세 번째 줄을 삽입해 보겠습니다.

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

실패 후 트랜잭션을 계속할 수 없는 이유는 무엇입니까? 사실은 우리가 변경 사항의 일부에 접근할 수 있는 방식으로 오류가 발생할 수 있다는 것입니다. 트랜잭션의 원자성은 물론이고 운영자도 위반하게 됩니다. 예제에서와 같이 운영자는 오류가 발생하기 전에 한 줄을 업데이트했습니다.

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