ဒါနဲ့ပတ်သက်တဲ့ ကိစ္စတွေကို ကျွန်တော်တို့ စဉ်းစားထားပါတယ်။ insulationဆုတ်ခွာမှုတွေ လုပ်ထားတယ်။ ဒေတာကို အဆင့်နိမ့်စွာ စုစည်းပါ။. နောက်ဆုံးတော့ စိတ်ဝင်စားစရာအကောင်းဆုံးအပိုင်းဖြစ်တဲ့ string versions ကိုရောက်ပါပြီ။

header ကို

ကျွန်ုပ်တို့ပြောခဲ့သည့်အတိုင်း၊ အတန်းတစ်ခုစီသည် ဒေတာဘေ့စ်တွင် ဗားရှင်းများစွာကို တစ်ပြိုင်နက်တည်း တည်ရှိနိုင်သည်။ ဗားရှင်းတစ်ခုသည် အခြားဗားရှင်းတစ်ခုနှင့် တစ်နည်းနည်းဖြင့် ကွဲပြားနေရပါမည်။ ဤရည်ရွယ်ချက်အတွက်၊ ဗားရှင်းတစ်ခုစီတွင် ဤဗားရှင်း၏ "အချိန်" ကို ဆုံးဖြတ်သည့် အမှတ်အသားနှစ်ခု (xmin နှင့် xmax)။ ကိုးကားချက်များတွင် - အချိန်မဟုတ်သောကြောင့်၊ သို့သော် အထူးတိုးမြင့်သည့် တန်ပြန်ကို အသုံးပြုသည်။ ပြီးတော့ ဒီကောင်တာက ငွေလွှဲတဲ့နံပါတ်ပါ။

(ပုံမှန်အတိုင်း၊ အဖြစ်မှန်က ပိုရှုပ်ထွေးသည်- ကောင်တာ၏ အကန့်အသတ်ရှိသော ဘစ်စွမ်းရည်ကြောင့် ငွေပေးငွေယူနံပါတ်သည် အချိန်ပြည့်မတိုးနိုင်ပါ။ သို့သော် အေးခဲသွားသောအခါတွင် ဤအသေးစိတ်အချက်အလက်များကို ကျွန်ုပ်တို့ကြည့်ရှုပါမည်။)

အတန်းတစ်ခုကို ဖန်တီးသောအခါ၊ xmin အား INSERT အမိန့်ကို ထုတ်ပြန်သည့် ငွေပေးငွေယူနံပါတ်သို့ သတ်မှတ်ထားပြီး xmax ကို ဗလာအဖြစ် ထားခဲ့သည်။

အတန်းတစ်ခုကို ဖျက်လိုက်သောအခါ၊ လက်ရှိဗားရှင်း၏ xmax တန်ဖိုးကို DELETE လုပ်ဆောင်သည့် ငွေပေးငွေယူ နံပါတ်ဖြင့် အမှတ်အသားပြုပါသည်။

အတန်းတစ်ခုကို UPDATE အမိန့်ဖြင့် မွမ်းမံသောအခါ၊ လုပ်ဆောင်ချက်နှစ်ခုကို အမှန်တကယ်လုပ်ဆောင်သည်- DELETE နှင့် INSERT။ အတန်း၏ လက်ရှိဗားရှင်းသည် xmax ကို UPDATE ပြုလုပ်သည့် ငွေပေးငွေယူ အရေအတွက်နှင့် ညီမျှစေသည်။ ထို့နောက် တူညီသောစာကြောင်း၏ ဗားရှင်းအသစ်ကို ဖန်တီးပြီး၊ ၎င်း၏ xmin တန်ဖိုးသည် ယခင်ဗားရှင်း၏ xmax တန်ဖိုးနှင့် တိုက်ဆိုင်နေသည်။

xmin နှင့် xmax အကွက်များကို အတန်းဗားရှင်းခေါင်းစီးတွင် ထည့်သွင်းထားသည်။ ဤအကွက်များအပြင်၊ ခေါင်းစီးတွင် အခြားသော ဥပမာများပါရှိသည်၊

• infomask သည် ဤဗားရှင်း၏ ဂုဏ်သတ္တိများကို သတ်မှတ်ပေးသည့် အတွဲများဖြစ်သည်။ သူတို့ထဲက တော်တော်များတယ်။ ဖြည်းဖြည်းချင်း အဓိက စဉ်းစားပါမယ်။
• ctid သည် တူညီသောလိုင်း၏ နောက်ထပ်ဗားရှင်းအသစ်သို့ လင့်ခ်တစ်ခုဖြစ်သည်။ အသစ်ဆုံး၊ လက်ရှိဗားရှင်းတစ်ခုအတွက်၊ ctid သည် ဤဗားရှင်းကိုယ်တိုင်ကို ရည်ညွှန်းသည်။ နံပါတ်တွင် ပုံစံ (x၊ y) ရှိပြီး x သည် စာမျက်နှာနံပါတ်ဖြစ်ပြီး y သည် array ရှိ အညွှန်းနံပါတ်ဖြစ်သည်။
• null bitmap - null value (NULL) ပါဝင်သည့် ပေးထားသောဗားရှင်းတစ်ခု၏ ထိုကော်လံများကို အမှတ်အသားပြုပါ။ NULL သည် သာမန်ဒေတာအမျိုးအစားတန်ဖိုးများထဲမှတစ်ခုမဟုတ်ပါ၊ ထို့ကြောင့် attribute ကို သီးခြားသိမ်းဆည်းထားရပါမည်။

ရလဒ်အနေဖြင့် header သည် အလွန်ကြီးမားသည် - လိုင်းဗားရှင်းတစ်ခုစီအတွက် အနည်းဆုံး 23 bytes ရှိပြီး အများအားဖြင့် NULL bitmap ကြောင့် ပို၍များပြားသည်။ ဇယားသည် "ကျဉ်းသည်" (ဆိုလိုသည်မှာ၊ ကော်လံအနည်းငယ်ပါရှိသည်) သည် အသုံးဝင်သောအချက်အလက်ထက် ပိုယူနိုင်သည်။

ထည့်သွင်း

ထည့်သွင်းခြင်းမှအစပြု၍ အဆင့်နိမ့် စာကြောင်းများ လုပ်ဆောင်ပုံကို အနီးကပ် လေ့လာကြည့်ကြပါစို့။

စမ်းသပ်မှုများအတွက်၊ ကော်လံနှစ်ခုနှင့် ၎င်းတို့ထဲမှ တစ်ခုပေါ်တွင် အညွှန်းတစ်ခုပါသော ဇယားအသစ်တစ်ခုကို ဖန်တီးကြပါစို့။

=> 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 extension ၏ heap_page_items လုပ်ဆောင်ချက်သည် သင့်အား pointers များနှင့် row versions များအကြောင်း အချက်အလက်များကို ရရှိစေပါသည်။

=> 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 ရှိ စကားလုံး heap သည် ဇယားများကို ရည်ညွှန်းကြောင်း သတိပြုပါ။ ဤသည်မှာ အမှိုက်ပုံဟူသော အသုံးအနှုန်း၏ နောက်ထပ်ထူးဆန်းသော အသုံးအနှုန်းဖြစ်သည်။ ဒေတာဖွဲ့စည်းပုံစားပွဲနှင့် ဘာမှမဆိုင်ပါ။ ဤနေရာတွင် စကားလုံးကို "အရာရာကို စုစည်းလိုက်သည်" ဟူသော အဓိပ္ပာယ်ဖြင့် အမိန့်ပေးထားသော အညွှန်းများကို ဆန့်ကျင်သည်။

လုပ်ဆောင်ချက်သည် ဒေတာကို နားလည်ရခက်သော ဖော်မတ်ဖြင့် “ဖြစ်သကဲ့သို့” ပြသည်။ ၎င်းကို သိရှိနိုင်ရန် ကျွန်ုပ်တို့သည် အချက်အလက်၏ တစ်စိတ်တစ်ပိုင်းကိုသာ ချန်ထားခဲ့ကာ ၎င်းကို ပုံဖော်ခြင်း-

=> 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 ညွှန်ပြချက်၏ အခြေအနေကို ပုံဖော်ထားသည်။ ဤတွင်၎င်းသည် "သာမန်" ဖြစ်သည် - ဆိုလိုသည်မှာ pointer သည် string ၏ဗားရှင်းကို အမှန်တကယ်ရည်ညွှန်းသည်။ တခြားအဓိပ္ပါယ်တွေကို နောက်မှကြည့်ပါမယ်။
• အချက်အလက်အားလုံးတွင် အတွဲနှစ်တွဲကိုသာ ယခုအချိန်အထိ ဖော်ထုတ်နိုင်ခဲ့သည်။ xmin_committed နှင့် xmin_aborted bits များသည် ငွေပေးငွေယူနံပါတ် xmin ကို ကျူးလွန်ခြင်းရှိမရှိ ဖော်ပြသည် (ဖျက်သိမ်းထားသည်)။ အလားတူ bit နှစ်ခုသည် ငွေပေးငွေယူနံပါတ် xmax ကို ရည်ညွှန်းသည်။

ငါတို့ ဘာကိုမြင်လဲ။ အတန်းတစ်ခုကို သင်ထည့်သွင်းသောအခါ၊ အညွှန်းကိန်း 1 သည် အတန်း၏ ပထမဆုံးနှင့် တစ်ခုတည်းသောဗားရှင်းကို ညွှန်ပြပြီး ဇယားစာမျက်နှာတွင် ပေါ်လာလိမ့်မည်။

string ဗားရှင်းတွင်၊ xmin အကွက်တွင် လက်ရှိ ငွေပေးငွေယူနံပါတ်ဖြင့် ဖြည့်ထားသည်။ ငွေပေးငွေယူသည် အသက်ဝင်နေဆဲဖြစ်သောကြောင့် xmin_committed နှင့် xmin_aborted bits နှစ်ခုလုံးကို သတ်မှတ်မထားပါ။

အတန်းဗားရှင်း ctid အကွက်သည် တူညီသောအတန်းကို ရည်ညွှန်းသည်။ ဆိုလိုသည်မှာ ဗားရှင်းအသစ် မရှိပါ။

xmax အကွက်တွင် ဤအတန်း၏ဤဗားရှင်းကို မဖျက်ရသေးဘဲ လက်ရှိဖြစ်နေသောကြောင့် dummy နံပါတ် 0 နှင့် ပြည့်နေပါသည်။ xmax_aborted bit ကိုသတ်မှတ်ထားသောကြောင့် ငွေပေးငွေယူများသည် ဤနံပါတ်ကိုအာရုံစိုက်မည်မဟုတ်ပါ။

ငွေပေးငွေယူနံပါတ်များသို့ အချက်အလက်ဘစ်များထည့်ခြင်းဖြင့် ဖတ်နိုင်စွမ်းရည်ကို မြှင့်တင်ရန် နောက်ထပ်ခြေလှမ်းတစ်ခုလှမ်းကြပါစို့။ ကျွန်ုပ်တို့သည် တောင်းဆိုချက်ကို တစ်ကြိမ်ထက်ပို၍ လိုအပ်သောကြောင့် လုပ်ဆောင်ချက်တစ်ခုကို ဖန်တီးကြပါစို့။

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

ဆင်တူသော်လည်း သိသိသာသာအသေးစိတ်နည်းသော အချက်အလက်များကို pseudo-columns xmin နှင့် xmax ကို အသုံးပြု၍ ဇယားကိုယ်တိုင်က ရယူနိုင်ပါသည်။

=> SELECT xmin, xmax, * FROM t;

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

fixation

ငွေပေးငွေယူတစ်ခု အောင်မြင်စွာပြီးမြောက်ပါက၊ ၎င်း၏ အခြေအနေကို မှတ်သားထားရန် လိုအပ်သည် - ၎င်းကို ကတိပြုထားကြောင်း သတိပြုပါ။ ဒါကိုလုပ်ဖို့၊ XACT လို့ ခေါ်တဲ့ ဖွဲ့စည်းပုံကို အသုံးပြုပြီး (ဗားရှင်း 10 မတိုင်ခင်က CLOG (commit log) လို့ ခေါ်ပြီး ဒီနာမည်ကို နေရာအမျိုးမျိုးမှာ တွေ့နိုင်ပါသေးတယ်)။

XACT သည် စနစ်ကတ်တလောက်ဇယားမဟုတ်ပါ။ ဤအရာများသည် PGDATA/pg_xact လမ်းညွှန်ရှိ ဖိုင်များဖြစ်သည်။ ၎င်းတို့တွင် ငွေပေးငွေယူတစ်ခုစီအတွက် ဘစ်နှစ်ခုပါရှိသည်- ကတိပြုထားပြီး၊ ဖျက်သိမ်းထားသည်- အတန်းဗားရှင်းခေါင်းစီးတွင်ကဲ့သို့ပင်။ ဤအချက်အလက်ကို အဆင်ပြေစေရန်အတွက်သာ ဖိုင်အများအပြားသို့ ပိုင်းခြားထားပါသည်၊ အေးခဲရန် စဉ်းစားသောအခါတွင် ကျွန်ုပ်တို့သည် ဤပြဿနာသို့ ပြန်သွားပါမည်။ ဤဖိုင်များနှင့်အတူ အလုပ်သည် အခြားသူများအားလုံးကဲ့သို့ စာမျက်နှာတစ်ခုပြီးတစ်ခု လုပ်ဆောင်ပါသည်။

ထို့ကြောင့်၊ XACT တွင် ငွေပေးငွေယူတစ်ခုကို ကတိပြုသောအခါ၊ ကတိပြုထားသောဘစ်ကို ဤလွှဲပြောင်းမှုအတွက် သတ်မှတ်သည်။ ဤသည်မှာ ကတိပြုစဉ်အတွင်း ဖြစ်ပျက်ခဲ့သမျှ (ကြိုတင်မှတ်တမ်းတင်ခြင်းမှတ်တမ်းအကြောင်း ကျွန်ုပ်တို့ မပြောရသေးသော်လည်း)။

အခြားငွေပေးငွေယူလုပ်ငန်းသည် ကျွန်ုပ်တို့ကြည့်ရှုခဲ့သည့် ဇယားစာမျက်နှာသို့ ဝင်ရောက်သည့်အခါ၊ မေးခွန်းများစွာကို ဖြေဆိုရမည်ဖြစ်သည်။

1. xmin အရောင်းအဝယ် ပြီးသွားပြီလား။ မဟုတ်ပါက၊ ဖန်တီးထားသော စာကြောင်း၏ဗားရှင်းကို မြင်နိုင်မည်မဟုတ်ပေ။
   ဤစစ်ဆေးမှုကို စံနမူနာ၏ မျှဝေမှတ်ဉာဏ်တွင် တည်ရှိပြီး ProcArray ဟုခေါ်သော အခြားဖွဲ့စည်းပုံအား ကြည့်ရှုခြင်းဖြင့် လုပ်ဆောင်သည်။ ၎င်းတွင် အသက်ဝင်နေသော လုပ်ငန်းစဉ်များအားလုံး၏စာရင်းတစ်ခုပါရှိပြီး တစ်ခုစီအတွက် ၎င်း၏လက်ရှိ (တက်ကြွသော) လွှဲပြောင်းမှုအရေအတွက်ကို ညွှန်ပြထားသည်။
2. ပြီးသွားပါက၊ ကတိကဝတ်ပြုခြင်း သို့မဟုတ် ပယ်ဖျက်ခြင်း မည်ကဲ့သို့လုပ်ဆောင်မည်နည်း။ ပယ်ဖျက်လိုက်လျှင် အတန်းဗားရှင်းကိုလည်း မြင်နိုင်မည်မဟုတ်ပေ။
   ဤသည်မှာ XACT အတွက်အတိအကျဖြစ်သည်။ သို့သော်၊ XACT ၏နောက်ဆုံးစာမျက်နှာများကို RAM တွင်ကြားခံများတွင်သိမ်းဆည်းထားသော်လည်း၊ အချိန်တိုင်း XACT စစ်ဆေးရန်စျေးကြီးနေသေးသည်။ ထို့ကြောင့်၊ ငွေပေးငွေယူအခြေအနေအား ဆုံးဖြတ်ပြီးသည်နှင့် ၎င်းကို string ဗားရှင်း၏ xmin_committed နှင့် xmin_aborted bits များသို့ စာရေးထားသည်။ ဤဘစ်များထဲမှ တစ်ခုကို သတ်မှတ်ပါက၊ ငွေပေးငွေယူ xmin အခြေအနေကို သိပြီး နောက်တစ်နေ့တွင် ငွေပေးငွေယူ XACT ကို ဝင်ရောက်ရန် မလိုအပ်ပါ။

အရောင်းအ၀ယ်ကိုယ်တိုင်က ဤဘစ်များကို အဘယ်ကြောင့် ထည့်သွင်းခြင်းမပြုသနည်း။ ထည့်သွင်းမှုတစ်ခု ပေါ်ပေါက်လာသောအခါတွင် အရောင်းအဝယ် အောင်မြင်မည်ဆိုသည်ကို မသိရသေးပေ။ ကတိကဝတ်ပြုသည့်အချိန်တွင် မည်သည့်စာမျက်နှာများကို ပြောင်းလဲခဲ့သည်ကို ရှင်းရှင်းလင်းလင်းမသိရပေ။ ထိုသို့သော စာမျက်နှာများစွာ ရှိနိုင်သည်၊ ၎င်းတို့ကို ကျက်မှတ်ခြင်းသည် အကျိုးမဖြစ်ထွန်းပါ။ ထို့အပြင်၊ အချို့သောစာမျက်နှာများကို ကြားခံကက်ရှ်မှ disk သို့ နှင်ထုတ်နိုင်သည်။ bits များကို ပြောင်းလဲရန် ၎င်းတို့ကို ထပ်မံဖတ်ရှုခြင်းသည် commit ကို သိသိသာသာ နှေးကွေးစေပါသည်။

ငွေစုခြင်း၏ အားနည်းချက်မှာ အပြောင်းအလဲများပြီးနောက်၊ မည်သည့်ငွေပေးငွေယူ (ရိုးရှင်းသောဖတ်ရှုခြင်း - 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 ငွေပေးငွေယူ အခြေအနေကို ဆုံးဖြတ်ပြီး အချက်အလက် bits တွင် ရေးရပါမည်-

=> 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 bit ကို ရှင်းထားသည်။

တက်ကြွသော ငွေပေးငွေယူနှင့် သက်ဆိုင်သော xmax ၏ သတ်မှတ်တန်ဖိုးသည် အတန်းလော့ခ်အဖြစ် လုပ်ဆောင်သည်ကို သတိပြုပါ။ အခြားငွေပေးငွေယူက ဤအတန်းကို အပ်ဒိတ်လုပ်ရန် သို့မဟုတ် ဖျက်လိုပါက၊ ငွေပေးငွေယူ xmax ကို အပြီးသတ်ရန် စောင့်ခိုင်းလိမ့်မည်။ ပိတ်ဆို့ခြင်းအကြောင်း နောက်မှပြောပါမည်။ ယခုအချိန်တွင်၊ အတန်းသော့ခတ်သည့်အရေအတွက်မှာ အကန့်အသတ်မရှိကြောင်း ကျွန်ုပ်တို့သတိပြုမိပါသည်။ ၎င်းတို့သည် RAM တွင် နေရာလွတ်မယူဘဲ စနစ်စွမ်းဆောင်ရည်သည် ၎င်းတို့၏နံပါတ်ကို မထိခိုက်စေပါ။ မှန်ပါသည်၊ “ရှည်” သော အရောင်းအ၀ယ်များတွင် အခြားအားနည်းချက်များ ရှိသည်၊ သို့သော် နောက်ပိုင်းတွင် ပိုများသည်။

လိုင်းကို ဖျက်လိုက်ရအောင်။

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

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

ငွေပေးငွေယူနံပါတ်ကို xmax အကွက်တွင် ရေးထားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရသော်လည်း အချက်အလက် bits များကို သတ်မှတ်မထားပါ။

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

update ကို

အပ်ဒိတ်သည် အတန်း၏ လက်ရှိဗားရှင်းကို ပထမဦးစွာ ဖျက်ပြီးနောက် အသစ်တစ်ခုကို ထည့်သွင်းသကဲ့သို့ အလုပ်လုပ်သည်။

=> 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 bit ကို ရှင်းလင်းထားသည်။

ယခု စာကြောင်း၏ ပထမဗားရှင်းသည် ဒုတိယအသစ် (t_ctid အကွက်) ကို ရည်ညွှန်းသည်။

ဒုတိယအညွှန်းသည် အညွှန်းစာမျက်နှာတွင် ပေါ်လာပြီး ဒုတိယတန်းတစ်ခုသည် ဇယားစာမျက်နှာရှိ ဒုတိယဗားရှင်းကို ရည်ညွှန်းသည်။

ဖျက်ခြင်းကဲ့သို့ပင်၊ အတန်း၏ပထမဗားရှင်းရှိ xmax တန်ဖိုးသည် အတန်းအား လော့ခ်ချထားကြောင်း ညွှန်ပြနေသည်။

ကောင်းပြီ၊ ငွေပေးငွေယူကို အပြီးသတ်လိုက်ရအောင်။

=> COMMIT;

အညွှန်းကိန်း

အခုထိတော့ ဇယားစာမျက်နှာတွေလောက်ပဲ ပြောဖြစ်သေးတယ်။ အညွှန်းကိန်းများအတွင်း ဘာဖြစ်သွားမလဲ။

အညွှန်းစာမျက်နှာများရှိ အချက်အလက်များသည် သီးခြားအညွှန်းအမျိုးအစားပေါ်မူတည်၍ များစွာကွဲပြားပါသည်။ အညွှန်းအမျိုးအစားတစ်ခုပင်လျှင် စာမျက်နှာအမျိုးအစားများ ကွဲပြားပါသည်။ ဥပမာအားဖြင့်၊ B-tree တွင် metadata စာမျက်နှာနှင့် "ပုံမှန်" စာမျက်နှာများရှိသည်။

သို့သော်၊ စာမျက်နှာတွင် အများအားဖြင့် အတန်းများနှင့် အတန်းများကိုယ်တိုင် (ဇယားစာမျက်နှာကဲ့သို့) ညွှန်ပြသည့် array တစ်ခုရှိသည်။ ထို့အပြင်၊ စာမျက်နှာ၏အဆုံးတွင် အထူးဒေတာအတွက် နေရာလွတ်ရှိသည်။

အညွှန်းကိန်းများတွင် အတန်းများသည် အညွှန်းအမျိုးအစားပေါ်မူတည်၍ အလွန်ကွဲပြားသောဖွဲ့စည်းပုံများ ရှိနိုင်သည်။ ဥပမာအားဖြင့်၊ B-tree တစ်ခုအတွက်၊ အရွက်စာမျက်နှာများနှင့်သက်ဆိုင်သည့်အတန်းများတွင် သက်ဆိုင်ရာဇယားအတန်းအတွက် အညွှန်းကိန်းသော့တန်ဖိုးနှင့် ကိုးကားချက် (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 သည် ၎င်းအား လွှဲပြောင်းပေးသည့်နံပါတ်များကို "သိမ်းဆည်းရန်" ခွင့်ပြုသည့် ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်မှုများကို အသုံးပြုသည်။

ငွေပေးငွေယူတစ်ခုသည် ဒေတာကိုသာဖတ်ပါက၊ အတန်းဗားရှင်းများ၏ မြင်နိုင်စွမ်းအပေါ် သက်ရောက်မှုမရှိပါ။ ထို့ကြောင့်၊ ဝန်ဆောင်မှုလုပ်ငန်းစဉ်သည် ငွေပေးငွေယူအတွက် virtual 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;

Nested ငွေလွှဲမှုများ

အမှတ်များသိမ်းဆည်းပါ။

SQL တွင်သတ်မှတ်ထားသည်။ အမှတ်များသိမ်းဆည်းပါ။ (savepoint) သည် ငွေပေးငွေယူ၏ တစ်စိတ်တစ်ပိုင်းကို လုံးဝနှောက်ယှက်ခြင်းမရှိဘဲ ပယ်ဖျက်နိုင်စေသည့် (savepoint)။ သို့သော်၊ ငွေပေးငွေယူသည် ၎င်း၏ပြောင်းလဲမှုအားလုံးအတွက် တူညီသောအခြေအနေရှိပြီး၊ ဒေတာကို ရုပ်ပိုင်းဆိုင်ရာအရ ပြန်ဖွင့်မည်မဟုတ်သောကြောင့် ၎င်းသည် အထက်ဖော်ပြပါပုံနှင့် မကိုက်ညီပါ။

ဤလုပ်ဆောင်ချက်ကို အကောင်အထည်ဖော်ရန်၊ savepoint တစ်ခုနှင့် ငွေပေးငွေယူကို သီးခြားများစွာခွဲထားသည်။ nested အရောင်းအဝယ်များ (subtransaction) သီးခြားစီ စီမံခန့်ခွဲနိုင်သည့် အခြေအနေ၊

Nested ငွေပေးငွေယူများတွင် ၎င်းတို့၏ကိုယ်ပိုင်နံပါတ်ရှိသည် (ပင်မငွေပေးငွေယူအရေအတွက်ထက် ပိုများသည်)။ XACT တွင် nested အရောင်းအ၀ယ်များ၏ အခြေအနေကို ပုံမှန်အတိုင်း မှတ်တမ်းတင်ထားသော်လည်း နောက်ဆုံးအခြေအနေသည် ပင်မငွေပေးငွေယူ၏ အခြေအနေပေါ်တွင် မူတည်သည်- ၎င်းကို ပယ်ဖျက်ပါက၊ ထို့နောက်တွင် အစုစပ်ငွေပေးချေမှုအားလုံးကိုလည်း ပယ်ဖျက်ပါသည်။

ငွေပေးငွေယူ nesting အကြောင်း အချက်အလက်ကို PGDATA/pg_subtrans directory အတွင်းရှိ ဖိုင်များတွင် သိမ်းဆည်းထားသည်။ ဖိုင်များကို XACT buffers များကဲ့သို့ပင် စုစည်းထားသည့် instance ၏ မျှဝေထားသော memory ရှိ buffers မှတဆင့် ဝင်ရောက်ကြည့်ရှုပါသည်။

ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရှိသော ငွေပေးငွေယူများဖြင့် nested ငွေပေးငွေယူများကို မရောထွေးပါနှင့်။ ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရငွေပေးငွေယူများသည် တစ်ဦးနှင့်တစ်ဦးအပေါ်တွင် မည်သို့မျှမမူတည်သော်လည်း၊ ပုံမှန် 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)

အခု save point တစ်ခုတင်ပြီး နောက်လိုင်းတစ်ခုထည့်လိုက်ရအောင်။

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

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

txid_current() လုပ်ဆောင်ချက်သည် nested အရောင်းအ၀ယ်နံပါတ်မဟုတ်ဘဲ ပင်မငွေပေးငွေယူနံပါတ်ကို ပြန်ပေးကြောင်း သတိပြုပါ။

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

save point သို့ ပြန်လှည့်ပြီး တတိယစာကြောင်းကို ထည့်ကြပါစို့။

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

စာမျက်နှာတွင် ပယ်ဖျက်ထားသော nested ငွေပေးငွေယူဖြင့် ထည့်ထားသော အတန်းကို ကျွန်ုပ်တို့ ဆက်လက်မြင်နေရပါသည်။

အပြောင်းအလဲတွေကို ကျွန်တော်တို့ ပြင်တယ်။

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

ယခု nested ငွေပေးငွေယူတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်အခြေအနေရှိကြောင်း ရှင်းရှင်းလင်းလင်း သိမြင်နိုင်ပါပြီ။

ထည့်သွင်းထားသော ငွေပေးငွေယူများကို SQL တွင် ပြတ်သားစွာ အသုံးမပြုနိုင်သည်ကို သတိပြုပါ ၊ ဆိုလိုသည်မှာ သင်သည် လက်ရှိကို မပြီးမြောက်ဘဲ ငွေပေးငွေယူအသစ်တစ်ခု စတင်နိုင်မည်မဟုတ်ကြောင်း သတိပြုပါ။ savepoints များအပြင် 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 သည် command တစ်ခုစီ၏ရှေ့တွင် သွယ်ဝိုက်သော save point ကို အမှန်တကယ် ထားရှိကြောင်း ခန့်မှန်းရန် မခက်ပါဘဲ၊ မအောင်မြင်ပါက ၎င်းကို rollback လုပ်သည် ။ ကယ်တင်ရေးမှတ်များ သတ်မှတ်ခြင်း (၎င်းတို့ကို နောက်ကြောင်းပြန်မလှည့်ဘဲ) တွင် အရေးပါသော အရာများ ပါဝင်သောကြောင့် ဤမုဒ်ကို မူရင်းအတိုင်း အသုံးမပြုပါ။

ဆက်ရန်။

source: www.habr.com