അതിനാൽ, ഇതുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾ ഞങ്ങൾ പരിഗണിച്ചു ഇൻസുലേഷൻ, കുറിച്ച് ഒരു പിന്മാറ്റം നടത്തി കുറഞ്ഞ തലത്തിൽ ഡാറ്റ സംഘടിപ്പിക്കുന്നു. ഒടുവിൽ ഞങ്ങൾ ഏറ്റവും രസകരമായ ഭാഗത്തിലെത്തി - സ്ട്രിംഗ് പതിപ്പുകൾ.

ഹെഡ്ഡർ

ഞങ്ങൾ ഇതിനകം പറഞ്ഞതുപോലെ, ഓരോ വരിയും ഒരേസമയം ഡാറ്റാബേസിലെ നിരവധി പതിപ്പുകളിൽ നിലനിൽക്കും. ഒരു പതിപ്പ് എങ്ങനെയെങ്കിലും മറ്റൊന്നിൽ നിന്ന് വേർതിരിക്കേണ്ടതാണ്. ഈ ആവശ്യത്തിനായി, ഓരോ പതിപ്പിനും ഈ പതിപ്പിന്റെ (xmin, xmax) പ്രവർത്തനത്തിന്റെ "സമയം" നിർണ്ണയിക്കുന്ന രണ്ട് അടയാളങ്ങളുണ്ട്. ഉദ്ധരണികളിൽ - കാരണം ഇത് സമയമല്ല ഉപയോഗിക്കുന്നത്, പക്ഷേ ഒരു പ്രത്യേക വർദ്ധിച്ചുവരുന്ന കൗണ്ടർ. ഈ കൗണ്ടറാണ് ഇടപാട് നമ്പർ.

(പതിവുപോലെ, യാഥാർത്ഥ്യം കൂടുതൽ സങ്കീർണ്ണമാണ്: കൗണ്ടറിന്റെ പരിമിതമായ ബിറ്റ് ശേഷി കാരണം ഇടപാട് നമ്പർ എല്ലായ്‌പ്പോഴും വർദ്ധിപ്പിക്കാൻ കഴിയില്ല. എന്നാൽ ഫ്രീസിംഗിൽ എത്തുമ്പോൾ ഞങ്ങൾ ഈ വിശദാംശങ്ങൾ വിശദമായി പരിശോധിക്കും.)

ഒരു വരി സൃഷ്ടിക്കുമ്പോൾ, INSERT കമാൻഡ് നൽകിയ ഇടപാട് നമ്പറിലേക്ക് xmin സജ്ജീകരിക്കും, കൂടാതെ xmax ശൂന്യമായി അവശേഷിക്കുന്നു.

ഒരു വരി ഇല്ലാതാക്കുമ്പോൾ, നിലവിലെ പതിപ്പിന്റെ xmax മൂല്യം DELETE നടത്തിയ ഇടപാടിന്റെ എണ്ണം കൊണ്ട് അടയാളപ്പെടുത്തുന്നു.

അപ്‌ഡേറ്റ് കമാൻഡ് ഉപയോഗിച്ച് ഒരു വരി പരിഷ്‌ക്കരിക്കുമ്പോൾ, യഥാർത്ഥത്തിൽ രണ്ട് പ്രവർത്തനങ്ങൾ നടത്തുന്നു: ഇല്ലാതാക്കുക, ചേർക്കുക. വരിയുടെ നിലവിലെ പതിപ്പ് അപ്‌ഡേറ്റ് നടത്തിയ ഇടപാടിന്റെ എണ്ണത്തിന് തുല്യമായ xmax സജ്ജീകരിക്കുന്നു. അതേ സ്ട്രിംഗിന്റെ ഒരു പുതിയ പതിപ്പ് പിന്നീട് സൃഷ്ടിക്കപ്പെടുന്നു; അതിന്റെ xmin മൂല്യം മുമ്പത്തെ പതിപ്പിന്റെ xmax മൂല്യവുമായി പൊരുത്തപ്പെടുന്നു.

xmin, xmax ഫീൽഡുകൾ വരി പതിപ്പ് തലക്കെട്ടിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഈ ഫീൽഡുകൾക്ക് പുറമേ, തലക്കെട്ടിൽ മറ്റുള്ളവയും അടങ്ങിയിരിക്കുന്നു, ഉദാഹരണത്തിന്:

ഈ പതിപ്പിന്റെ സവിശേഷതകൾ നിർവചിക്കുന്ന ബിറ്റുകളുടെ ഒരു പരമ്പരയാണ് infomask. അവയിൽ ധാരാളം ഉണ്ട്; പ്രധാനമായവ ഞങ്ങൾ ക്രമേണ പരിഗണിക്കും.
ctid അതേ വരിയുടെ അടുത്ത, പുതിയ പതിപ്പിലേക്കുള്ള ഒരു ലിങ്കാണ്. ഒരു സ്ട്രിംഗിന്റെ ഏറ്റവും പുതിയതും നിലവിലുള്ളതുമായ പതിപ്പിന്, ctid ഈ പതിപ്പിനെ തന്നെ സൂചിപ്പിക്കുന്നു. നമ്പറിന് ഫോം (x,y) ഉണ്ട്, ഇവിടെ x എന്നത് പേജ് നമ്പറാണ്, y എന്നത് അറേയിലെ സൂചിക സംഖ്യയാണ്.
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)

പേജിന്റെ ഉള്ളടക്കം നോക്കാം. പേജ്ഇൻസ്‌പെക്റ്റ് വിപുലീകരണത്തിന്റെ 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 പോയിന്ററിന്റെ അവസ്ഥ മനസ്സിലാക്കി. ഇവിടെ ഇത് "സാധാരണ" ആണ് - ഇതിനർത്ഥം പോയിന്റർ യഥാർത്ഥത്തിൽ സ്ട്രിംഗിന്റെ പതിപ്പിനെ സൂചിപ്പിക്കുന്നു എന്നാണ്. മറ്റ് അർത്ഥങ്ങൾ നമുക്ക് പിന്നീട് നോക്കാം.
എല്ലാ വിവര ബിറ്റുകളിലും, ഇതുവരെ രണ്ട് ജോഡികളെ മാത്രമേ തിരിച്ചറിഞ്ഞിട്ടുള്ളൂ. 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-ൽ ഒരു ഇടപാട് നടത്തുമ്പോൾ, ഈ ഇടപാടിനായി പ്രതിബദ്ധതയുള്ള ബിറ്റ് സജ്ജീകരിക്കും. കമ്മിറ്റ് ചെയ്യുമ്പോൾ സംഭവിക്കുന്നത് ഇതാണ് (ഞങ്ങൾ ഇതുവരെ പ്രീ-റെക്കോർഡിംഗ് ലോഗിനെക്കുറിച്ച് സംസാരിക്കുന്നില്ലെങ്കിലും).

നമ്മൾ ഇപ്പോൾ നോക്കിയ പട്ടിക പേജിലേക്ക് മറ്റൊരു ഇടപാട് പ്രവേശിക്കുമ്പോൾ, അതിന് നിരവധി ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകേണ്ടിവരും.

xmin ഇടപാട് പൂർത്തിയായോ? ഇല്ലെങ്കിൽ, സ്ട്രിംഗിന്റെ സൃഷ്‌ടിച്ച പതിപ്പ് ദൃശ്യമാകരുത്.
മറ്റൊരു ഘടന നോക്കിയാണ് ഈ പരിശോധന നടത്തുന്നത്, അത് ഉദാഹരണത്തിന്റെ പങ്കിട്ട മെമ്മറിയിൽ സ്ഥിതിചെയ്യുന്നു, അതിനെ ProcArray എന്ന് വിളിക്കുന്നു. എല്ലാ സജീവ പ്രക്രിയകളുടെയും ഒരു ലിസ്റ്റ് ഇതിൽ അടങ്ങിയിരിക്കുന്നു, ഓരോന്നിനും അതിന്റെ നിലവിലുള്ള (സജീവമായ) ഇടപാടിന്റെ എണ്ണം സൂചിപ്പിച്ചിരിക്കുന്നു.
പൂർത്തിയാക്കിയാൽ, പിന്നെ എങ്ങനെ - കമ്മിറ്റ് ചെയ്യുന്നതിലൂടെയോ റദ്ദാക്കുന്നതിലൂടെയോ? റദ്ദാക്കിയാൽ, വരി പതിപ്പും ദൃശ്യമാകരുത്.
ഇതാണ് കൃത്യമായി 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 പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കാൻ അത് നിർബന്ധിതരാകും. തടയുന്നതിനെക്കുറിച്ച് പിന്നീട് കൂടുതൽ സംസാരിക്കാം. ഇപ്പോൾ, വരി ലോക്കുകളുടെ എണ്ണം പരിധിയില്ലാത്തതാണെന്ന് ഞങ്ങൾ ശ്രദ്ധിക്കുന്നു. അവ റാമിൽ ഇടം എടുക്കുന്നില്ല, കൂടാതെ സിസ്റ്റം പ്രകടനം അവരുടെ നമ്പറിൽ നിന്ന് കഷ്ടപ്പെടുന്നില്ല. ശരിയാണ്, "ദീർഘമായ" ഇടപാടുകൾക്ക് മറ്റ് ദോഷങ്ങളുമുണ്ട്, എന്നാൽ പിന്നീട് കൂടുതൽ.

നമുക്ക് ലൈൻ ഇല്ലാതാക്കാം.

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

സൂചികകൾ

ഇതുവരെ നമ്മൾ ടേബിൾ പേജുകളെ കുറിച്ച് മാത്രമാണ് സംസാരിച്ചത്. സൂചികകൾക്കുള്ളിൽ എന്താണ് സംഭവിക്കുന്നത്?

നിർദ്ദിഷ്ട തരം സൂചികയെ ആശ്രയിച്ച് സൂചിക പേജുകളിലെ വിവരങ്ങൾ വളരെയധികം വ്യത്യാസപ്പെടുന്നു. ഒരു തരം സൂചികയിൽ പോലും വ്യത്യസ്ത തരം പേജുകൾ ഉണ്ട്. ഉദാഹരണത്തിന്, ഒരു ബി-ട്രീയിൽ ഒരു മെറ്റാഡാറ്റ പേജും "പതിവ്" പേജുകളും ഉണ്ട്.

എന്നിരുന്നാലും, പേജിൽ സാധാരണയായി വരികളിലേക്കും വരികളിലേക്കും പോയിന്ററുകളുടെ ഒരു നിരയുണ്ട് (ഒരു പട്ടിക പേജ് പോലെ). കൂടാതെ, പേജിന്റെ അവസാനം പ്രത്യേക ഡാറ്റയ്ക്ക് ഇടമുണ്ട്.

സൂചികയിലെ വരികൾക്ക് സൂചികയുടെ തരം അനുസരിച്ച് വളരെ വ്യത്യസ്തമായ ഘടനകളും ഉണ്ടാകാം. ഉദാഹരണത്തിന്, ഒരു ബി-ട്രീയുടെ, ലീഫ് പേജുകളുമായി ബന്ധപ്പെട്ട വരികളിൽ ഇൻഡെക്സിംഗ് കീ മൂല്യവും അനുബന്ധ പട്ടിക നിരയിലേക്കുള്ള ഒരു റഫറൻസും (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 നൽകുന്നു. നമ്പറിൽ ഒരു പ്രോസസ് ഐഡിയും ഒരു സീക്വൻസ് നമ്പറും അടങ്ങിയിരിക്കുന്നു.

ഈ നമ്പർ നൽകുന്നതിന് എല്ലാ പ്രക്രിയകളും തമ്മിൽ സമന്വയം ആവശ്യമില്ല, അതിനാൽ വളരെ വേഗതയുള്ളതാണ്. ഫ്രീസിംഗിനെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ വെർച്വൽ നമ്പറുകൾ ഉപയോഗിക്കുന്നതിനുള്ള മറ്റൊരു കാരണം നമുക്ക് പരിചയപ്പെടും.

ഡാറ്റ സ്നാപ്പ്ഷോട്ടുകളിൽ വെർച്വൽ നമ്പറുകൾ ഒരു തരത്തിലും കണക്കിലെടുക്കുന്നില്ല.

വ്യത്യസ്ത സമയങ്ങളിൽ, ഇതിനകം ഉപയോഗിച്ച നമ്പറുകളുള്ള സിസ്റ്റത്തിൽ വെർച്വൽ ഇടപാടുകൾ ഉണ്ടായിരിക്കാം, ഇത് സാധാരണമാണ്. എന്നാൽ അത്തരം ഒരു നമ്പർ ഡാറ്റ പേജുകളിൽ എഴുതാൻ കഴിയില്ല, കാരണം അടുത്ത തവണ പേജ് ആക്സസ് ചെയ്യുമ്പോൾ അതിന്റെ എല്ലാ അർത്ഥവും നഷ്ടപ്പെട്ടേക്കാം.

=> 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 യഥാർത്ഥത്തിൽ ഓരോ കമാൻഡിനും മുമ്പായി ഒരു സൂക്ഷ്‌മമായ സേവ് പോയിന്റ് ഇടുന്നു എന്ന് ഊഹിക്കാൻ പ്രയാസമില്ല, പരാജയപ്പെട്ടാൽ അതിലേക്ക് ഒരു റോൾബാക്ക് ആരംഭിക്കുന്നു. ഈ മോഡ് ഡിഫോൾട്ടായി ഉപയോഗിക്കുന്നില്ല, കാരണം സേവ് പോയിന്റുകൾ സജ്ജീകരിക്കുന്നതിൽ (അവയിലേക്ക് തിരികെ പോകാതെ പോലും) കാര്യമായ ഓവർഹെഡ് ഉൾപ്പെടുന്നു.

തുടർച്ച.

അവലംബം: www.habr.com

എംവിസിസി-3. സ്ട്രിംഗ് പതിപ്പുകൾ

ഹെഡ്ഡർ

കൂട്ടിച്ചേര്ക്കുക

ഫിക്സേഷൻ

ഇല്ലാതാക്കുക

റദ്ദാക്കല്

അപ്ഡേറ്റ് ചെയ്യുക

സൂചികകൾ

വെർച്വൽ ഇടപാടുകൾ

നെസ്റ്റഡ് ഇടപാടുകൾ

പോയിന്റുകൾ സംരക്ഷിക്കുക

പ്രവർത്തനങ്ങളുടെ പിശകുകളും ആറ്റോമിസിറ്റിയും

ഒരു അഭിപ്രായം ചേർക്കുക

എംവിസിസി-3. സ്ട്രിംഗ് പതിപ്പുകൾ

ഹെഡ്ഡർ

കൂട്ടിച്ചേര്ക്കുക

ഫിക്സേഷൻ

ഇല്ലാതാക്കുക

റദ്ദാക്കല്

അപ്ഡേറ്റ് ചെയ്യുക

സൂചികകൾ

വെർച്വൽ ഇടപാടുകൾ

നെസ്റ്റഡ് ഇടപാടുകൾ

പോയിന്റുകൾ സംരക്ഷിക്കുക

പ്രവർത്തനങ്ങളുടെ പിശകുകളും ആറ്റോമിസിറ്റിയും

ഒരു അഭിപ്രായം ചേർക്കുക മറുപടി റദ്ദാക്കാൻ

ഒരു അഭിപ്രായം ചേർക്കുക