LISTEN और NOTIFY PostgreSQL में एक built-in publish/subscribe messaging system प्रदान करते हैं — एक session किसी channel पर notification भेज सकता है, और उस channel पर सुन रहे अन्य sessions इसे तुरंत प्राप्त कर लेते हैं। यह बिना polling के database से real-time events को push करने का एक हल्का तरीका है।
LISTEN order_created;
NOTIFY order_created, ;
LISTEN किसी channel को subscribe करता है; NOTIFY उस पर publish करता है (एक वैकल्पिक text payload के साथ)। Listeners को asynchronously सूचित किया जाता है — किसी polling की आवश्यकता नहीं।
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
PERFORM pg_notify('order_created', NEW.id::text); -- notify with the new id
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER order_notify AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
NOTIFY को एक trigger के साथ जोड़ने से database data बदलने पर स्वतः events push कर सकता है (नया order, status update) — channel पर सुन रहे application servers real time में प्रतिक्रिया देते हैं।
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
(no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
proper broker (RabbitMQ, Kafka) or a queue table.
LISTEN/NOTIFY एक उपयोगी, कुछ हद तक कम-ज्ञात PostgreSQL feature है जो built-in pub/sub messaging प्रदान करता है, जो बिना polling के applications में real-time reactivity जोड़ने के लिए मूल्यवान है।
मुख्य मूल्य database को सक्षम बनाने में है कि जब कुछ होता है (एक नया order, एक status change) तो वह सुन रहे application sessions को तुरंत events push करे — आमतौर पर triggers के साथ जोड़ा जाता है ताकि data परिवर्तन स्वतः listeners को सूचित करें, जिन पर application servers प्रतिक्रिया देते हैं (websockets को push करना, caches को invalidate करना, background work को trigger करना)।
यह मूल्यवान है क्योंकि यह परिवर्तनों की जाँच के लिए database को बार-बार polling करने की अक्षमता के बिना real-time event-driven व्यवहार प्रदान करता है (एक आम, बर्बादीपूर्ण pattern जिसे LISTEN/NOTIFY सुरुचिपूर्ण ढंग से प्रतिस्थापित करता है)।
तंत्र को समझना (subscribe करने के लिए LISTEN, publish करने के लिए NOTIFY, data परिवर्तनों पर स्वचालित notification के लिए triggers के साथ) और applications इसका उपयोग कैसे करते हैं (real-time प्रतिक्रियाओं को चलाने के लिए events सुनना) केवल PostgreSQL का उपयोग करके responsive, event-driven applications बनाने के लिए उपयोगी है।
समान रूप से महत्वपूर्ण है सीमाओं को जानना: notifications persist नहीं होते (यदि कोई नहीं सुन रहा तो खो जाते हैं — कोई durability गारंटी नहीं), छोटे payloads होते हैं, और केवल commit के बाद fire होते हैं — इसलिए यह हल्के real-time signaling के लिए उपयुक्त है, न कि एक durable message broker (RabbitMQ, Kafka) का प्रतिस्थापन जब reliability और persistence मायने रखते हैं।
चूँकि real-time reactivity एक आम आवश्यकता है और LISTEN/NOTIFY इसे हल्के मामलों के लिए हासिल करने का एक built-in, polling-मुक्त तरीका प्रदान करता है, इसे समझना — pub/sub तंत्र, trigger pattern, और सबसे महत्वपूर्ण इसकी सीमाएँ (कब यह पर्याप्त है बनाम कब एक वास्तविक broker की आवश्यकता है) — event-driven applications बनाने के लिए मूल्यवान, व्यावहारिक रूप से प्रासंगिक PostgreSQL ज्ञान है, एक उपयोगी built-in feature जिसे अक्सर अनदेखा किया जाता है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें