PostgreSQL में पंक्तियों को अपडेट के रूप में लॉक कर दिया जाएगा - वास्तव में, जिस तरह से यह वास्तव में काम करता है वह यह है कि प्रत्येक टपल (पंक्ति का संस्करण) में एक सिस्टम फ़ील्ड होता है जिसे xmin कहा जाता है यह इंगित करने के लिए कि किस लेन-देन ने उस टपल को चालू किया (सम्मिलित या अद्यतन करके) और एक सिस्टम फ़ील्ड जिसे xmax कहा जाता है यह इंगित करने के लिए कि किस लेनदेन की अवधि समाप्त हो गई है (अपडेट या डिलीट करके)। जब आप डेटा एक्सेस करते हैं, तो यह इन मानों के विरुद्ध आपके सक्रिय "स्नैपशॉट" की जांच करके यह निर्धारित करने के लिए प्रत्येक टपल की जांच करता है कि यह आपके लेन-देन के लिए दृश्यमान है या नहीं।
यदि आप एक अद्यतन निष्पादित कर रहे हैं और आपकी खोज स्थितियों से मेल खाने वाले टपल में एक xmin है जो इसे आपके स्नैपशॉट और एक सक्रिय लेनदेन के xmax के लिए दृश्यमान बना देगा, तो यह उस लेनदेन के पूरा होने की प्रतीक्षा में अवरुद्ध हो जाता है। यदि लेन-देन जिसने पहले टपल को अपडेट किया था, वापस आ जाता है, तो आपका लेन-देन जाग जाता है और पंक्ति को संसाधित करता है; यदि पहला लेन-देन होता है, तो आपका लेन-देन जाग जाता है और वर्तमान लेनदेन अलगाव स्तर के आधार पर कार्रवाई करता है।
जाहिर है, एक गतिरोध अलग-अलग क्रम में पंक्तियों के साथ ऐसा होने का परिणाम है। रैम में कोई रो-लेवल लॉक नहीं है जो एक ही समय में सभी पंक्तियों के लिए प्राप्त किया जा सकता है, लेकिन यदि पंक्तियों को उसी क्रम में अपडेट किया जाता है तो आपके पास सर्कुलर लॉकिंग नहीं हो सकती है। दुर्भाग्य से, सुझाए गए IN(1, 2) वाक्यविन्यास इसकी गारंटी नहीं देता है। अलग-अलग सत्रों में अलग-अलग लागत कारक सक्रिय हो सकते हैं, एक पृष्ठभूमि "विश्लेषण" कार्य एक योजना और दूसरे की पीढ़ी के बीच तालिका के लिए आंकड़े बदल सकता है, या यह एक seqscan का उपयोग कर सकता है और PostgreSQL अनुकूलन से प्रभावित हो सकता है जो एक नया seqscan का कारण बनता है पहले से चल रहे एक में शामिल होने के लिए और डिस्क I/O को कम करने के लिए "लूप अराउंड"।
यदि आप एक बार में एक ही क्रम में, एप्लिकेशन कोड में या कर्सर का उपयोग करके अपडेट करते हैं, तो आपके पास केवल साधारण अवरोधन होगा, गतिरोध नहीं। सामान्य तौर पर, हालांकि, संबंधपरक डेटाबेस क्रमांकन विफलताओं के लिए प्रवण होते हैं, और उन्हें एक ढांचे के माध्यम से एक्सेस करना सबसे अच्छा होता है जो उन्हें SQLSTATE के आधार पर पहचान लेगा और स्वचालित रूप से पूरे लेनदेन को शुरू से ही पुनः प्रयास करेगा। PostgreSQL में क्रमांकन विफलता में हमेशा 40001 या 40P01 का SQLSTATE होगा।
http://www.postgresql.org/docs/current/interactive/mvcc-intro.html
