એક ડેવલપરે CREATE OR REPLACE FUNCTION નો ઉપયોગ કરીને હાલના ફંક્શનમાં એક વૈકલ્પિક આર્ગ્યુમેન્ટ ઉમેર્યા પછી પ્રોડક્શન PostgreSQL ડિપ્લોયમેન્ટ ક્રેશ થઈ ગયું. આ ફેરફારને કારણે એક જ નામ ધરાવતા બે ફંક્શન બની ગયા, જેનાથી ડેટાબેઝે “function is not unique” એરર આપી અને API એ 400 એરર દર્શાવી. આ ઘટના દર્શાવે છે કે કેવી રીતે એક નાની માઈગ્રેશન ભૂલ લાઈવ સ્કીમાને છૂપી રીતે બગાડી શકે છે અને શા માટે માત્ર કોડ-લેવલની તપાસ પૂરતી નથી.
શું ભૂલ થઈ હતી
ટીમને એક સ્ટોર્ડ પ્રોસિજર સાથે વધારાનું, વૈકલ્પિક પેરામીટર ઉમેરવાની જરૂર હતી. તેઓએ CREATE OR REPLACE FUNCTION … ચલાવ્યું, એવું માનીને કે તે જૂની વ્યાખ્યાને ઓવરરાઈટ કરી દેશે. PostgreSQL ત્યારે જ ફંક્શનને રિપ્લેસ કરે છે જ્યારે આર્ગ્યુમેન્ટ લિસ્ટ બરાબર મેચ થાય છે. સિગ્નેચર બદલવાથી મૂળ ફંક્શનને અસ્પૃશ્ય રાખીને એક બિલકુલ નવી ફંક્શન એન્ટ્રી રચાય છે.
કારણ કે નવા આર્ગ્યુમેન્ટમાં ડિફોલ્ટ વેલ્યુ હતી, તેથી જૂની સંખ્યામાં આર્ગ્યુમેન્ટ આપતા કોલર્સ બંને વ્યાખ્યાઓ સાથે મેચ થઈ શકતા હતા. PostgreSQL નક્કી કરી શક્યું નહીં કે કયા ફંક્શનને ઇનવોક કરવું અને તેણે “function is not unique” એરર ફેંકી, જે API તરફથી 400 રિસ્પોન્સ તરીકે દેખાઈ.
કોડ રિપોઝિટરીમાં માત્ર એક જ વ્યાખ્યા દેખાતી હતી, અને સોર્સ ટ્રી સ્કેન કરતી કસ્ટમ સ્ક્રિપ્ટે કોઈ ડુપ્લીકેટ રિપોર્ટ કર્યું નહોતું. ડુપ્લીકેટ માત્ર ડેટાબેઝમાં જ હતું, જે સર્વર પર જૂની માઈગ્રેશન ફાઇલ ફરીથી એક્ઝિક્યુટ કરવાથી ઉભું થયું હતું.
માઈગ્રેશન કેમ છૂટી ગયું
જે માઈગ્રેશને વૈકલ્પિક પેરામીટર ઉમેર્યું હતું તેણે ફક્ત CREATE OR REPLACE FUNCTION ચલાવ્યું હતું. જ્યારે માઈગ્રેશન બીજી વાર ચાલ્યું—કદાચ રોલબેક પછી અથવા રિપીટ ડિપ્લોયમેન્ટ દરમિયાન—ત્યારે ડેટાબેસે આ કમાન્ડને “હાલનાને બદલો” ને બદલે “નવો ઓવરલોડ ઉમેરો” તરીકે ગણ્યો. માઈગ્રેશને પરિણામી સ્થિતિની ચકાસણી કરી નહોતી, તેથી ડુપ્લીકેટ વગર નોંધ્યે જ ટકી રહ્યું.
રિપોઝિટરી તપાસતી સ્ક્રિપ્ટે સોર્સ ફાઇલોની તપાસ કરી હતી, લાઈવ સ્કીમાની નહીં. તે આગળના દરવાજા પર નજર રાખી રહી હતી જ્યારે બગ પાછળના દરવાજામાંથી પ્રવેશ્યો હતો.
જોખમ
એક જ અસ્પષ્ટ ફંક્શન તેના પર નિર્ભર હોય તેવી કોઈપણ સર્વિસને ઠપ કરી શકે છે. આમાં જો ફંક્શનની સંખ્યા ખોટી હોય તો ટ્રાન્ઝેક્શન રોલબેક કરવું અને સ્કીમા કેશને રિલોડ કરવા માટે નોટિફાય કરવાનો સમાવેશ થતો હતો.
માઈગ્રેશનને કેવી રીતે સુરક્ષિત રાખવું
ટીમે સ્પષ્ટ ચેક્સ સાથે માઈગ્રેશન ફરીથી બનાવ્યું, જે તેને સેલ્ફ-એસરટિંગ ઓપરેશનમાં ફેરવે છે:
- ટ્રાન્ઝેક્શન શરૂ કરો જેથી કોઈપણ નિષ્ફળતા આખા ફેરફારને રોલબેક કરી શકે.
- નવું વર્ઝન બનાવતા પહેલા જૂનું ફંક્શન સ્પષ્ટપણે ડ્રોપ કરો, જેથી ખાતરી થાય કે માત્ર એક જ વ્યાખ્યા અસ્તિત્વમાં છે.
- ઇચ્છિત સિગ્નેચર સાથે નવું ફંક્શન બનાવો.
pg_catalogમાં આપેલ નામ સાથેના ફંક્શન્સની ગણતરી કરો અને ખાતરી કરો કે સંખ્યા બરાબર એક જ છે.- જો ગણતરી અલગ હોય, તો ટ્રાન્ઝેક્શન રોલબેક કરો, જેથી ડુપ્લીકેટ ટકી ન રહે.
- સ્કીમા કેશને નોટિફાય કરો જેથી તે રિલોડ થાય અને પછીના ક્વેરીઝ અપડેટેડ વ્યાખ્યા જોઈ શકે.
કોડ સાચો છે તેવું માની લેવાને બદલે ડેટાબેઝને “કયા ફંક્શન્સ હાજર છે?” તેમ પૂછીને, માઈગ્રેશન વારંવાર ચલાવવા, આંશિક ડિપ્લોયમેન્ટ અથવા મેન્યુઅલ એડિટ્સ સામે વિશ્વસનીય બને છે.
વિરોધ પક્ષનો તર્ક: સુવિધા વિરુદ્ધ સુરક્ષા
CREATE OR REPLACE FUNCTION આકર્ષક છે કારણ કે તે ડેવલપર્સને અલગ ડ્રોપ સ્ટેટમેન્ટ્સ લખ્યા વગર ઝડપથી ઇટરેટ કરવાની મંજૂરી આપે છે. એવા વાતાવરણમાં જ્યાં માઈગ્રેશન્સ એક જ વાર ચાલે છે અને ક્યારેય ફરીથી ચાલતા નથી, ત્યાં આ શોર્ટકટ બરાબર કામ કરે છે. જોખમ ત્યારે આવે છે જ્યારે માઈગ્રેશન્સ ફરીથી રન કરવામાં આવે—પછી તે ટેસ્ટ ડેટાબેઝ રીસેટ કરતી CI પાઇપલાઇન્સ હોય, ઓટોમેટેડ રોલબેક હોય અથવા પ્રોડક્શનમાં મેન્યુઅલ રી-એપ્લિકેશન હોય.
મુખ્ય વાત (Takeaway)
CREATE OR REPLACE સાથે ફંક્શનની સિગ્નેચર બદલવાથી રિપ્લેસમેન્ટની ખાતરી મળતી નથી—જો આર્ગ્યુમેન્ટ લિસ્ટ અલગ હોય તો PostgreSQL છૂપી રીતે ઓવરલોડ બનાવી દેશે. જે પ્રોડક્શન એન્વાયરમેન્ટ્સ માઈગ્રેશન્સ પર નિર્ભર છે તેમણે માત્ર સોર્સ કોડ જ નહીં, પરંતુ પરિણામી સ્કીમાની પણ ચકાસણી કરવી જોઈએ. સ્પષ્ટ ડ્રોપ્સ, ટ્રાન્ઝેક્શનલ ચેક્સ અને પોસ્ટ-માઈગ્રેશન એસરશન્સનો સમાવેશ કરવાથી એક સુવિધાજનક શોર્ટકટ એક વિશ્વસનીય અને પુનરાવર્તિત પ્રક્રિયામાં ફેરવાઈ જાય છે.