LISTEN és NOTIFY egy beépített publish/subscribe üzenetküldő rendszert biztosítanak a PostgreSQL-ben — egy session értesítést küldhet egy csatornán, és más session-ök, amelyek ezen a csatornán figyelnek, azonnal megkapják azt. Ez egy könnyű módja az adatbázisból származó valós idejű események küldésének anélkül, hogy polling-ra lenne szükség.
LISTEN order_created;
NOTIFY order_created, ;
A LISTEN feliratkozik egy csatornára; a NOTIFY közzétesz rá (opcionális szöveg payload-dal). A hallgatók aszinkron módon kapnak értesítést — nincs szükség polling-ra.
-- 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
A NOTIFY trigger-rel való kombinálása lehetővé teszi az adatbázisnak, hogy automatikusan küldjön eseményeket az adatok megváltozásakor (új megrendelés, státusz frissítés) — az alkalmazás szerverek, amelyek a csatornán figyelnek, valós időben reagálnak.
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.
A LISTEN/NOTIFY egy hasznos, valamivel kevésbé ismert PostgreSQL funkció, amely beépített pub/sub üzenetküldést biztosít, értékes a valós idejű reaktivitás alkalmazásokhoz való hozzáadásához anélkül, hogy polling-ra lenne szükség.
Az alapvető érték az, hogy az adatbázis eseményeket küldhet közvetlenül a hallgató alkalmazás session-öknek, amikor valami történik (egy új megrendelés, egy státusz módosítás) — tipikusan trigger-ekkel kombinálva, így az adatok módosulása automatikusan értesíti a hallgatókat, amelyekre az alkalmazás szerverek reagálnak (websocket-ekbe küldve, cache-ket érvénytelenítve, háttér munkát indítva).
Ez azért értékes, mert valós idejű eseményvezérelt viselkedést biztosít anélkül, hogy az adatbázist ismételten le kellene pollingozni a változások ellenőrzéséhez (egy gyakori, pazarló minta, amelyet a LISTEN/NOTIFY elegánsan helyettesít).
A mechanizmus megértése (LISTEN feliratkozásra, NOTIFY közzétételre, trigger-ek az adatok módosítása során automatikus értesítéshez) és az alkalmazások által való felhasználása (események figyelése valós idejű reagálások meghajtásához) hasznos az ügyfélreaktív, eseményvezérelt alkalmazások PostgreSQL-ből való felépítéséhez.
Egyenértékűen fontos a korlátozások ismerete: az értesítések nem perzisztensek (elvesznek, ha senki sem figyel — nincsenek tartóssági garanciák), kis payload-dal rendelkeznek, és csak az commit után aktiválódnak — így könnyű valós idejű szignalizálásra alkalmas, nem a tartós üzenetkezelő (RabbitMQ, Kafka) helyettesítésére, amikor a megbízhatóság és a perzisztencia fontos.
Mivel a valós idejű reaktivitás gyakori szükséglet, és a LISTEN/NOTIFY egy beépített, polling-mentes módot kínál arra, hogy ezt könnyű esetek során elérjük, annak megértése — a pub/sub mechanizmus, a trigger minta, és lényegileg annak korlátozásai (amikor elegendő, illetve amikor valódi broker szükséges) — értékes, gyakorlatilag releváns PostgreSQL tudás az eseményvezérelt alkalmazások felépítéséhez, egy hasznos beépített funkció, amely gyakran kimarad a figyelem alól.