एका डेव्हलपरने CREATE OR REPLACE FUNCTION वापरून अस्तित्वात असलेल्या फंक्शनमध्ये एक पर्यायी आर्ग्युमेंट (optional argument) जोडल्यामुळे प्रोडक्शन PostgreSQL डिप्लॉयमेंट क्रॅश झाले. या बदलामुळे एकाच नावाचे दोन फंक्शन तयार झाले, ज्यामुळे डेटाबेसने “function is not unique” असा एरर दिला आणि API ने 400 एरर दाखवला. ही घटना दर्शवते की मायग्रेशनमधील एक छोटी चूक लाइव्ह स्कीमाचे (live schema) शांतपणे नुकसान कशी करू शकते आणि केवळ कोड-लेव्हलवरील तपासणी पुरेशी का नाही.

काय चुकले

टीमला एका स्टोअर्ड प्रोसिजरमध्ये (stored procedure) एक अतिरिक्त, पर्यायी पॅरामीटर जोडायचा होता. त्यांनी CREATE OR REPLACE FUNCTION … चालवले, असे गृहीत धरून की यामुळे जुनी व्याख्या (definition) ओव्हरराईट होईल. PostgreSQL फंक्शन तेव्हाच रिप्लेस करते जेव्हा आर्ग्युमेंट लिस्ट (argument list) तंतोतंत जुळते. सिग्नेचर (signature) बदलल्यामुळे मूळ फंक्शन न बदलता एक पूर्णपणे नवीन फंक्शन एन्ट्री तयार होते.

नवीन आर्ग्युमेंटला डिफॉल्ट व्हॅल्यू असल्यामुळे, जे कॉलर्स जुन्या संख्येने आर्ग्युमेंट्स पुरवत होते, ते दोन्हीपैकी कोणत्याही डेफिनेशनशी जुळू शकत होते. PostgreSQL ठरवू शकले नाही की कोणते फंक्शन कॉल करायचे आणि त्यामुळे “function is not unique” हा एरर आला, जो API कडून 400 रिस्पॉन्स म्हणून समोर आला.

कोड रिपॉझिटरीमध्ये एकच डेफिनेशन दिसत होती आणि सोर्स ट्री (source tree) स्कॅन करणाऱ्या कस्टम स्क्रिप्टने कोणतेही डुप्लिकेट आढळल्याचे सांगितले नाही. हे डुप्लिकेट केवळ डेटाबेसमध्ये होते, जे सर्व्हरवर जुनी मायग्रेशन फाईल पुन्हा रन केल्यामुळे निर्माण झाले होते.

मायग्रेशन का सुटले

पर्यायी पॅरामीटर जोडणाऱ्या मायग्रेशनमध्ये फक्त CREATE OR REPLACE FUNCTION वापरले होते. जेव्हा मायग्रेशन दुसऱ्यांदा चालले—कदाचित रोलबॅकनंतर किंवा रिपीट डिप्लॉयमेंट दरम्यान—तेव्हा डेटाबेसने या कमांडला "जुने रिप्लेस करणे" ऐवजी "नवीन ओव्हरलोड जोडणे" असे मानले. मायग्रेशनने resulting state ची पडताळणी केली नाही, त्यामुळे ते डुप्लिकेट न कळत कायम राहिले.

रिपॉझिटरी तपासणारी स्क्रिप्ट सोर्स फाइल्स तपासत होती, लाइव्ह स्कीमा नाही. ती समोरच्या दरवाजाकडे पाहत होती, तर बग मागच्या दरवाजातून शिरला होता.

धोके

एक संदिग्ध फंक्शन (ambiguous function) त्यावर अवलंबून असलेल्या कोणत्याही सर्व्हिसला ठप्प करू शकते. यावर उपाय म्हणून, जर फंक्शनची संख्या चुकीची असेल तर ट्रान्झॅक्शन रोलबॅक करणे आणि स्कीमा कॅशेला (schema cache) रीलोड करण्यासाठी सूचित करणे आवश्यक होते.

मायग्रेशन सुरक्षित कसे ठेवायचे

टीमने स्पष्ट तपासणीसह (explicit checks) मायग्रेशन पुन्हा तयार केले, ज्यामुळे ते एक सेल्फ-असेर्टिंग ऑपरेशन (self-asserting operation) बनले:

  • ट्रान्झॅक्शन सुरू करा (Start a transaction) जेणेकरून कोणत्याही अपयशाच्या वेळी संपूर्ण बदल रोलबॅक होईल.
  • नवीन व्हर्जन तयार करण्यापूर्वी जुने फंक्शन स्पष्टपणे ड्रॉप (Drop) करा, जेणेकरून फक्त एकच डेफिनेशन अस्तित्वात राहील याची खात्री होईल.
  • हवी असलेली सिग्नेचर वापरून नवीन फंक्शन तयार करा.
  • pg_catalog मध्ये दिलेल्या नावाचे फंक्शन किती आहेत ते मोजा (Count the functions) आणि संख्या नेमकी एक आहे याची खात्री करा.
  • जर संख्या वेगळी असेल तर ट्रान्झॅक्शन रोलबॅक (Roll back) करा, जेणेकरून डुप्लिकेट कायम राहणार नाही.
  • स्कीमा कॅशेला (schema cache) रीलोड करण्यासाठी सूचित करा, जेणेकरून पुढील क्वेरीजना अपडेटेड डेफिनेशन दिसेल.

कोड बरोबर आहे असे गृहीत धरण्याऐवजी डेटाबेसला “कोणती फंक्शन्स उपलब्ध आहेत?” असे विचारल्यामुळे, मायग्रेशन पुन्हा पुन्हा रन करणे, अंशतः डिप्लॉयमेंट किंवा मॅन्युअल एडिट्स यांपासून सुरक्षित आणि विश्वसनीय बनते.

प्रतिवाद: सोय विरुद्ध सुरक्षा (convenience vs. safety)

CREATE OR REPLACE FUNCTION हे डेव्हलपर्सना वेगवान काम करण्यास मदत करते कारण त्यांना वेगळे 'drop' स्टेटमेंट्स लिहावे लागत नाहीत. ज्या वातावरणात मायग्रेशन्स एकदाच चालतात आणि पुन्हा कधीही रन होत नाहीत, तिथे ही पद्धत व्यवस्थित काम करते. धोका तेव्हा निर्माण होतो जेव्हा मायग्रेशन्स पुन्हा रन केले जातात—मग ते टेस्ट डेटाबेस रिसेट करणाऱ्या CI पाइपलाइन्समुळे असो, ऑटोमेटेड रोलबॅकमुळे असो किंवा प्रोडक्शनमध्ये मॅन्युअल रि-अप्लिकेशनमुळे असो.

निष्कर्ष (Takeaway)

CREATE OR REPLACE वापरून फंक्शनची सिग्नेचर बदलल्याने रिप्लेसमेंटची खात्री मिळत नाही—जर आर्ग्युमेंट लिस्ट वेगळी असेल तर PostgreSQL शांतपणे एक ओव्हरलोड तयार करेल. मायग्रेशन्सवर अवलंबून असलेल्या प्रोडक्शन एन्व्हायरनमेंटमध्ये केवळ सोर्स कोड नाही, तर resulting schema ची पडताळणी करणे आवश्यक आहे. स्पष्ट 'drops', ट्रान्झॅक्शनल चेक्स आणि पोस्ट-मायग्रेशन अ‍ॅसर्शन्सचा वापर केल्यामुळे एक सोपी पद्धत एका विश्वसनीय आणि पुनरावृत्ती करण्यायोग्य (repeatable) प्रक्रियेत रूपांतरित होते.