Joel Stevenson <joelstevenson@xxxxxxx> writes: >> Also, it might be worth enabling log_lock_waits to see if the slow >> notifies are due to having to wait on some lock or other. > Turning on log_lock_waits shows that there is a lot of waiting for > locks on the pg_listener table ala: Interesting. The LISTEN/NOTIFY mechanism itself takes ExclusiveLock on pg_listener, but never for very long at a time (assuming pg_listener doesn't get horribly bloated, which we know isn't happening for you). Another thought that comes to mind is that maybe the delays you see come from these lock acquisitions getting blocked behind autovacuums of pg_listener. I did not see that while trying to replicate your problem, but maybe the issue requires more update load on pg_listener than the test script can create by itself, or maybe some nondefault autovacuum setting is needed --- what are you using? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
