તેથી, અમે સંબંધિત મુદ્દાઓ પર વિચાર કર્યો છે ઇન્સ્યુલેશન, અને વિશે એક પીછેહઠ કરી હતી નીચા સ્તરે ડેટાનું આયોજન. અને અંતે અમે સૌથી રસપ્રદ ભાગ પર પહોંચ્યા - શબ્દમાળા આવૃત્તિઓ.

હેડર

આપણે પહેલેથી જ કહ્યું છે તેમ, દરેક પંક્તિ એકસાથે ડેટાબેઝમાં અનેક સંસ્કરણોમાં અસ્તિત્વમાં હોઈ શકે છે. એક સંસ્કરણ કોઈક રીતે બીજાથી અલગ હોવું જોઈએ. આ હેતુ માટે, દરેક સંસ્કરણમાં બે ગુણ છે જે આ સંસ્કરણની ક્રિયાનો "સમય" નક્કી કરે છે (xmin અને xmax). અવતરણમાં - કારણ કે તે સમયનો ઉપયોગ થતો નથી, પરંતુ એક વિશેષ વધતો કાઉન્ટર છે. અને આ કાઉન્ટર ટ્રાન્ઝેક્શન નંબર છે.

(હંમેશની જેમ, વાસ્તવિકતા વધુ જટિલ છે: કાઉન્ટરની મર્યાદિત બીટ ક્ષમતાને કારણે વ્યવહાર નંબર સતત વધી શકતો નથી. પરંતુ જ્યારે આપણે ઠંડું થઈ જઈશું ત્યારે અમે આ વિગતોને વિગતવાર જોઈશું.)

જ્યારે પંક્તિ બનાવવામાં આવે છે, ત્યારે xmin એ ટ્રાન્ઝેક્શન નંબર પર સેટ થાય છે જેણે INSERT આદેશ જારી કર્યો હતો, અને xmax ખાલી છોડી દેવામાં આવે છે.

જ્યારે કોઈ પંક્તિ કાઢી નાખવામાં આવે છે, ત્યારે વર્તમાન સંસ્કરણનું xmax મૂલ્ય તે વ્યવહારની સંખ્યા સાથે ચિહ્નિત થાય છે જેણે કાઢી નાખ્યું હતું.

જ્યારે પંક્તિ અપડેટ આદેશ દ્વારા સંશોધિત કરવામાં આવે છે, ત્યારે ખરેખર બે કામગીરી કરવામાં આવે છે: કાઢી નાખો અને દાખલ કરો. પંક્તિનું વર્તમાન સંસ્કરણ xmax ને અપડેટ કરેલ વ્યવહારની સંખ્યાની બરાબર સેટ કરે છે. તે જ શબ્દમાળાનું નવું સંસ્કરણ પછી બનાવવામાં આવે છે; તેનું xmin મૂલ્ય અગાઉના સંસ્કરણના xmax મૂલ્ય સાથે એકરુપ છે.

xmin અને xmax ક્ષેત્રો પંક્તિ સંસ્કરણ હેડરમાં શામેલ છે. આ ક્ષેત્રો ઉપરાંત, હેડરમાં અન્ય શામેલ છે, ઉદાહરણ તરીકે:

• ઇન્ફોમાસ્ક એ બિટ્સની શ્રેણી છે જે આ સંસ્કરણના ગુણધર્મોને વ્યાખ્યાયિત કરે છે. તેમાંના ઘણા બધા છે; અમે ધીમે ધીમે મુખ્ય મુદ્દાઓ ધ્યાનમાં લઈશું.
• ctid એ સમાન લાઇનના આગલા, નવા સંસ્કરણની લિંક છે. સ્ટ્રીંગના નવીનતમ, સૌથી વર્તમાન સંસ્કરણ માટે, ctid એ આ સંસ્કરણનો જ ઉલ્લેખ કરે છે. નંબરમાં ફોર્મ (x,y) છે, જ્યાં x એ પેજ નંબર છે, y એ એરેમાં ઇન્ડેક્સ નંબર છે.
• નલ બીટમેપ - આપેલ સંસ્કરણના તે કૉલમ્સને ચિહ્નિત કરે છે જેમાં નલ મૂલ્ય (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: (પૃષ્ઠ નંબર, અનુક્રમણિકા નંબર) જેવો જ દેખાય.
• 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 વ્યવહાર પૂર્ણ થયો છે? જો નહિં, તો શબ્દમાળાનું બનાવેલ સંસ્કરણ દૃશ્યમાન હોવું જોઈએ નહીં.
   આ તપાસ અન્ય સ્ટ્રક્ચરને જોઈને કરવામાં આવે છે, જે ઉદાહરણની વહેંચાયેલ મેમરીમાં સ્થિત છે અને તેને પ્રોકએરે કહેવાય છે. તે બધી સક્રિય પ્રક્રિયાઓની સૂચિ ધરાવે છે, અને દરેક માટે તેના વર્તમાન (સક્રિય) વ્યવહારની સંખ્યા દર્શાવેલ છે.
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 પૂર્ણ થાય ત્યાં સુધી રાહ જોવાની ફરજ પાડવામાં આવશે. અમે પછીથી અવરોધિત કરવા વિશે વધુ વાત કરીશું. હમણાં માટે, અમે ફક્ત નોંધીએ છીએ કે પંક્તિ તાળાઓની સંખ્યા અમર્યાદિત છે. તેઓ રેમમાં જગ્યા લેતા નથી અને સિસ્ટમની કામગીરી તેમની સંખ્યાથી પીડાતી નથી. સાચું, "લાંબા" વ્યવહારોના અન્ય ગેરફાયદા છે, પરંતુ તે પછીથી વધુ.

ચાલો લીટી કાઢી નાખીએ.

=> 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 hint બિટ પંક્તિ સંસ્કરણ પર સેટ કરવામાં આવશે. 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 માં વ્યાખ્યાયિત પોઈન્ટ સાચવો (savepoint), જે તમને વ્યવહારના ભાગને સંપૂર્ણપણે વિક્ષેપિત કર્યા વિના રદ કરવાની મંજૂરી આપે છે. પરંતુ આ ઉપરોક્ત રેખાકૃતિમાં બંધબેસતું નથી, કારણ કે વ્યવહાર તેના તમામ ફેરફારો માટે સમાન સ્થિતિ ધરાવે છે, અને ભૌતિક રીતે કોઈ ડેટા રોલબેક કરવામાં આવતો નથી.

આ કાર્યક્ષમતાને અમલમાં મૂકવા માટે, સેવપોઇન્ટ સાથેના વ્યવહારને કેટલાક અલગમાં વિભાજિત કરવામાં આવે છે નેસ્ટેડ વ્યવહારો (સબટ્રાન્ઝેક્શન), જેનું સ્ટેટસ અલગથી મેનેજ કરી શકાય છે.

નેસ્ટેડ ટ્રાન્ઝેક્શનનો પોતાનો નંબર હોય છે (મુખ્ય ટ્રાન્ઝેક્શનની સંખ્યા કરતા વધારે). નેસ્ટેડ ટ્રાન્ઝેક્શન્સની સ્થિતિ XACT માં સામાન્ય રીતે રેકોર્ડ કરવામાં આવે છે, પરંતુ અંતિમ સ્થિતિ મુખ્ય વ્યવહારની સ્થિતિ પર આધારિત છે: જો તે રદ કરવામાં આવે છે, તો પછી તમામ નેસ્ટેડ વ્યવહારો પણ રદ કરવામાં આવે છે.

ટ્રાન્ઝેક્શન નેસ્ટિંગ વિશેની માહિતી PGDATA/pg_subtrans ડિરેક્ટરીમાં ફાઇલોમાં સંગ્રહિત થાય છે. ફાઇલોને દાખલાની વહેંચાયેલ મેમરીમાં બફર્સ દ્વારા એક્સેસ કરવામાં આવે છે, જે XACT બફર્સની જેમ ગોઠવવામાં આવે છે.

નેસ્ટેડ વ્યવહારોને સ્વાયત્ત વ્યવહારો સાથે ગૂંચવશો નહીં. સ્વાયત્ત વ્યવહારો કોઈપણ રીતે એકબીજા પર આધાર રાખતા નથી, પરંતુ નેસ્ટેડ વ્યવહારો કરે છે. નિયમિત PostgreSQL માં કોઈ સ્વાયત્ત વ્યવહારો નથી, અને, કદાચ, શ્રેષ્ઠ માટે: તે ખૂબ જ ભાગ્યે જ જરૂરી છે, અને અન્ય DBMSs માં તેમની હાજરી દુરુપયોગને ઉત્તેજિત કરે છે, જેનાથી દરેક વ્યક્તિ પીડાય છે.

ચાલો કોષ્ટક સાફ કરીએ, વ્યવહાર શરૂ કરીએ અને પંક્તિ દાખલ કરીએ:

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