How to use PostgreSQL's LISTEN/NOTIFY as a simple message queue with psycopg2 and asyncio

listen.py

import asyncio
import psycopg2

# dbname should be the same for the notifying process
conn = psycopg2.connect(host="localhost", dbname="example", user="example", password="example")
conn.set_isolation_level(psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)

cursor = conn.cursor()
cursor.execute(f"LISTEN match_updates;")

def handle_notify():
    conn.poll()
    for notify in conn.notifies:
        print(notify.payload)
    conn.notifies.clear()

# It works with uvloop too:
# import uvloop
# loop = uvloop.new_event_loop()
# asyncio.set_event_loop(loop)

loop = asyncio.get_event_loop()
loop.add_reader(conn, handle_notify)
loop.run_forever()

notify.py

import time
import psycopg2

# dbname should be the same for the listening process
conn = psycopg2.connect(host="localhost", dbname="example", user="example", password="example")

cursor = conn.cursor()
conn.set_isolation_level(psycopg2.extensions.ISOLATION_LEVEL_AUTOCOMMIT)

while True:
    val = time.time()
    cursor.execute(f"NOTIFY match_updates, '{val}';")
    time.sleep(1)

@kissgyorgy this is absolutely fantastic. I'm trying to ATTACH PARTITIONS to a table on inserts by using the listener. So, if I run the statements in listen-new.py and then perform my required insert statements right after it, then how do i exit/terminate the listener (since in the script it uses loop.run_forever()). I intend to run the listener only while I am running the insert statements thru my Python program.

@kissgyorgy this is absolutely fantastic. I'm trying to ATTACH PARTITIONS to a table on inserts by using the listener. So, if I run the statements in listen-new.py and then perform my required insert statements right after it, then how do i exit/terminate the listener (since in the script it uses loop.run_forever()). I intend to run the listener only while I am running the insert statements thru my Python program.

I don't understand exactly what you are trying to do, but maybe a TRIGGER would be better for your use-case? Triggers can be used for partitioned tables too:

Creating a row-level trigger on a partitioned table will cause an identical “clone” trigger to be created on each of its existing partitions; and any partitions created or attached later will have an identical trigger, too.

https://www.postgresql.org/docs/current/sql-createtrigger.html

Isn't there an SQL injection in the NOTIFY part?

Isn't there an SQL injection in the NOTIFY part?

1. If you look at the definition of SQL injection at Wikipedia, in the second sentence it says "... when user input is either incorrectly filtered...". There is no user input in the snippet.
2. This is an example of how to wire it up, people shouldn't copy-paste code from the internet verbatim.

@d33tah You can call the pg_notify function instead of the NOTIFY directive. You should be able to do parameter substitution with psycopg2 then.

Thank you so much for the detailed reply!

It would be quite useful @kissgyorgy if you have time to make a similar gist for psycopg version 3