LISTEN(7)

πŸ“¦ version 13.23, in opensuse-leap 16.0

πŸ’… LISTEN(7) β€” the PostgreSQL LISTEN page, bestie edition ✨

okay so this is the LISTEN page from the PostgreSQL 13.23 Documentation, and honestly? it's giving "quietly powerful." it's about listening for notifications, and no cap, it's one of the most underrated little commands in the whole system. let's get into it πŸŽ€


🌸 NAME 🌸

LISTEN β€” listen for a notification πŸ¦‹


✨ SYNOPSIS ✨

LISTEN channel

that's it. that's the whole vibe. one command, one channel, and you're tuned in πŸ’–


πŸ’œ DESCRIPTION πŸ’œ

so LISTEN registers the current session as a listener on the notification channel named channel. and if the current session is already registered as a listener for this notification channel? literally nothing happens. no error, no drama, nothing is done. it's just like "yeah babe i already know" 🫢

whenever the command NOTIFY channel is invoked β€” whether it's by this session or another one connected to the same database β€” all the sessions currently listening on that notification channel get notified, and each one will in turn notify its connected client application. it's giving group chat energy, fr fr πŸ“£

a session can be unregistered for a given notification channel with the UNLISTEN command. and listen (pun intended), a session's listen registrations are automatically cleared when the session ends β€” so you don't have to clean up after yourself, it's iconic like that ✨

now the part where it gets a little technical, stay with me πŸ‘‘

the method a client application must use to detect notification events depends on which PostgreSQL application programming interface it uses:

  • with the libpq library, the application issues LISTEN as an ordinary SQL command, and then must periodically call the function PQnotifies to find out whether any notification events have been received.
  • other interfaces such as libpgtcl provide higher-level methods for handling notify events. in fact, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. like, don't do it, bestie.

see the documentation for the interface you're using for more details β€” the manual's words, not mine πŸ’…


πŸŽ€ PARAMETERS πŸŽ€

  • channel β€” name of a notification channel (any identifier). that's the whole thing. any identifier you want, it's yours πŸ“

⭐ NOTES ⭐

okay this section is important, so pay attention, no scrolling past πŸ™ˆ

  • LISTEN takes effect at transaction commit. so if LISTEN or UNLISTEN is executed within a transaction that later rolls back, the set of notification channels being listened to is unchanged. like it never happened πŸ’€
  • a transaction that has executed LISTEN cannot be prepared for two-phase commit. important. write it down.
  • there is a race condition when first setting up a listening session πŸƒβ€β™€οΈπŸ’¨ β€” if concurrently-committing transactions are sending notify events, exactly which of those will the newly listening session receive? the answer is that the session will receive all events committed after an instant during the transaction's commit step. but that is slightly later than any database state that the transaction could have observed in queries. sneaky, right?

this leads to the following rule for using LISTEN, and it's the main character of this whole section πŸ‘‘:

  1. first execute (and commit!) that command,
  2. then in a new transaction inspect the database state as needed by the application logic,
  3. then rely on notifications to find out about subsequent changes to the database state.

the first few received notifications might refer to updates already observed in the initial database inspection, but this is usually harmless. phew 😌

NOTIFY(7) contains a more extensive discussion of the use of LISTEN and NOTIFY β€” so if you want the full lore, go read that one too πŸ¦‹


🌈 EXAMPLES 🌈

configure and execute a listen/notify sequence from psql:

LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.

look at that. clean. gorgeous. ate and left no crumbs πŸ’…βœ¨


πŸ¦‹ COMPATIBILITY πŸ¦‹

there is no LISTEN statement in the SQL standard. nope. not a thing there. this is a PostgreSQL original, iykyk πŸ’œ


πŸ”₯ SEE ALSO πŸ”₯


and that's the whole page, bestie 🫢 go forth and listen (the command, not the emotional labour). this was PostgreSQL 13.23, dated 2025, and honestly? she's timeless. mwah πŸ’‹πŸ’–πŸŽ€

πŸ“¦ where this page comes from