সুতরাং, আমরা সম্পর্কিত বিষয় বিবেচনা করেছি অন্তরণ, এবং সম্পর্কে একটি পশ্চাদপসরণ করা একটি নিম্ন স্তরে তথ্য সংগঠিত. এবং অবশেষে আমরা সবচেয়ে আকর্ষণীয় অংশ পেয়েছি - স্ট্রিং সংস্করণ।

হেডার

আমরা আগেই বলেছি, প্রতিটি সারি ডাটাবেসের বিভিন্ন সংস্করণে একই সাথে থাকতে পারে। একটি সংস্করণকে অন্য একটি থেকে আলাদা করা আবশ্যক৷ এই উদ্দেশ্যে, প্রতিটি সংস্করণে দুটি চিহ্ন রয়েছে যা এই সংস্করণের কর্মের "সময়" নির্ধারণ করে (xmin এবং xmax)৷ উদ্ধৃতিতে - কারণ এটি সময় নয় যেমন ব্যবহার করা হয়, তবে একটি বিশেষ বৃদ্ধি পাল্টা। আর এই কাউন্টার হল লেনদেন নম্বর।

(স্বাভাবিক হিসাবে, বাস্তবতা আরও জটিল: কাউন্টারের সীমিত বিট ক্ষমতার কারণে লেনদেনের সংখ্যা সব সময় বাড়তে পারে না। তবে আমরা যখন হিমায়িত হব তখন আমরা এই বিবরণগুলি বিস্তারিতভাবে দেখব।)

যখন একটি সারি তৈরি করা হয়, তখন xmin লেনদেন নম্বরে সেট করা হয় যা INSERT কমান্ড জারি করে এবং xmax খালি রাখা হয়।

যখন একটি সারি মুছে ফেলা হয়, তখন বর্তমান সংস্করণের xmax মানটি মুছে ফেলার লেনদেনের সংখ্যা দিয়ে চিহ্নিত করা হয়।

যখন একটি সারি একটি UPDATE কমান্ড দ্বারা পরিবর্তিত হয়, তখন দুটি ক্রিয়াকলাপ বাস্তবে সঞ্চালিত হয়: DELETE এবং INSERT৷ সারির বর্তমান সংস্করণটি আপডেট করা লেনদেনের সংখ্যার সমান xmax সেট করে। একই স্ট্রিং এর একটি নতুন সংস্করণ তারপর তৈরি করা হয়; এর xmin মান পূর্ববর্তী সংস্করণের xmax মানের সাথে মিলে যায়।

xmin এবং xmax ক্ষেত্রগুলি সারি সংস্করণ শিরোনামে অন্তর্ভুক্ত করা হয়েছে। এই ক্ষেত্রগুলি ছাড়াও, শিরোনামে অন্যান্য রয়েছে, উদাহরণস্বরূপ:

• infomask হল বিটগুলির একটি সিরিজ যা এই সংস্করণের বৈশিষ্ট্যগুলিকে সংজ্ঞায়িত করে। তাদের মধ্যে বেশ অনেক আছে; আমরা ধীরে ধীরে প্রধান বেশী বিবেচনা করা হবে.
• 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

মনে রাখবেন পোস্টগ্রেএসকিউএল-এর হিপ শব্দটি টেবিলকে বোঝায়। এটি শব্দটির আরেকটি অদ্ভুত ব্যবহার - একটি গাদা পরিচিত তথ্য কাঠামো, যা টেবিলের সাথে মিল নেই। এখানে শব্দটি "সবকিছু একসাথে নিক্ষেপ করা হয়" অর্থে ব্যবহৃত হয়েছে, অর্ডারকৃত সূচকের বিপরীতে।

ফাংশনটি ডেটা দেখায় "যেমন আছে", এমন একটি বিন্যাসে যা বোঝা কঠিন। এটি বের করার জন্য, আমরা তথ্যের শুধুমাত্র কিছু অংশ ছেড়ে দেব এবং এটির পাঠোদ্ধার করব:

=> 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 লেনদেন সম্পন্ন হয়েছে? যদি না হয়, তাহলে স্ট্রিংয়ের তৈরি সংস্করণটি দৃশ্যমান হওয়া উচিত নয়।
   এই চেকটি অন্য একটি কাঠামো দেখে সঞ্চালিত হয়, যা উদাহরণের ভাগ করা মেমরিতে অবস্থিত এবং এটিকে বলা হয় 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;

সূচকের

এ পর্যন্ত আমরা শুধু টেবিল পেজ সম্পর্কে কথা বলেছি। ইনডেক্সের ভিতরে কি হয়?

সুনির্দিষ্ট ধরনের সূচকের উপর নির্ভর করে সূচী পাতার তথ্য ব্যাপকভাবে পরিবর্তিত হয়। এবং এমনকি এক ধরনের সূচকের বিভিন্ন ধরনের পৃষ্ঠা রয়েছে। উদাহরণস্বরূপ, একটি বি-ট্রিতে একটি মেটাডেটা পৃষ্ঠা এবং "নিয়মিত" পৃষ্ঠা রয়েছে।

যাইহোক, পৃষ্ঠায় সাধারণত সারি এবং সারিগুলির জন্য পয়েন্টারগুলির একটি অ্যারে থাকে (ঠিক একটি টেবিল পৃষ্ঠার মতো)। এছাড়াও, পৃষ্ঠার শেষে বিশেষ ডেটার জন্য স্থান রয়েছে।

ইনডেক্সের সারিগুলিও সূচকের ধরণের উপর নির্ভর করে খুব আলাদা কাঠামো থাকতে পারে। উদাহরণস্বরূপ, একটি বি-বৃক্ষের জন্য, পাতার পৃষ্ঠাগুলির সাথে সম্পর্কিত সারিগুলিতে ইনডেক্সিং কী মান এবং সংশ্লিষ্ট টেবিলের সারিতে একটি রেফারেন্স (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-এ কোন স্বায়ত্তশাসিত লেনদেন নেই, এবং, সম্ভবত, সর্বোত্তম জন্য: এগুলি খুব, খুব কমই প্রয়োজন, এবং অন্যান্য 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