लेन-देन अलगाव से पेज:
एक EXPLAIN उस पर SELECT आपको बता सकता है कि क्वेरी योजना क्या ली जा रही है, लेकिन यदि तालिका छोटी (या खाली!) यह संपूर्ण तालिका पर एक विधेय लॉक का कारण बनेगा, जिससे जब भी कोई अन्य लेन-देन तालिका में कुछ भी करता है तो क्रमांकन विफल हो जाता है।
मेरे सिस्टम पर:
isolation=# EXPLAIN SELECT * from mydevice where cid = 1;
QUERY PLAN
----------------------------------------------------------
Seq Scan on mydevice (cost=0.00..23.38 rows=5 width=46)
Filter: (cid = 1)
(2 rows)
आप एक अनुक्रमणिका जोड़ने का प्रयास कर सकते हैं और उसे इसका उपयोग करने के लिए बाध्य कर सकते हैं:
isolation=# CREATE INDEX mydevice_cid_key ON mydevice (cid);
CREATE INDEX
isolation=# SET enable_seqscan = off;
SET
isolation=# EXPLAIN SELECT * from mydevice where cid = 1;
QUERY PLAN
----------------------------------------------------------------------------------
Index Scan using mydevice_cid_key on mydevice (cost=0.00..8.27 rows=1 width=46)
Index Cond: (cid = 1)
(2 rows)
हालाँकि, यह सही समाधान नहीं है। आइए थोड़ा सा बैक अप लें।
Serializable यह गारंटी देने के लिए है कि लेन-देन का बिल्कुल वैसा ही प्रभाव होगा जैसे कि वे एक के बाद एक चल रहे थे, इस तथ्य के बावजूद कि आप वास्तव में इन लेनदेन को समवर्ती रूप से चला रहे हैं। PostgreSQL के पास अनंत संसाधन नहीं हैं, इसलिए जबकि यह सच है कि यह डेटा पर विधेय लॉक लगाता है जिसे आपकी क्वेरी वास्तव में एक्सेस करती है, "डेटा" का अर्थ "पंक्तियों की वापसी" से अधिक हो सकता है।
PostgreSQL क्रमांकन विफलताओं को ध्वजांकित करना चुनता है जब उसे लगता है कि कोई समस्या हो सकती है, न कि जब यह निश्चित हो। (इसलिए यह पेज लॉक के लिए पंक्ति लॉक को कैसे सामान्यीकृत करता है।) यह डिज़ाइन विकल्प झूठी सकारात्मकता का कारण बनता है, जैसे कि आपके उदाहरण में। झूठी सकारात्मकता आदर्श से कम है, हालांकि, यह अलगाव शब्दार्थ की शुद्धता को प्रभावित नहीं करती है।
त्रुटि संदेश है:
ERROR: could not serialize access due to read/write dependencies among transactions
DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
HINT: The transaction might succeed if retried.
वह संकेत प्रमुख है। आपके एप्लिकेशन को क्रमांकन विफलताओं को पकड़ने और संपूर्ण कार्रवाई का पुन:प्रयास करने . की आवश्यकता है . यह सच है जब भी SERIALIZABLE चल रहा है -- यह समवर्ती होने के बावजूद धारावाहिक शुद्धता की गारंटी देता है, लेकिन यह आपके आवेदन की सहायता के बिना ऐसा नहीं कर सकता है। एक और तरीका रखो, यदि आप वास्तव में समवर्ती संशोधन कर रहे हैं, तो PostgreSQL अलगाव आवश्यकताओं को पूरा करने का एकमात्र तरीका है कि आप अपने आवेदन को खुद को क्रमबद्ध करने के लिए कहें। इस प्रकार:
