Joel Stevenson <joelstevenson@xxxxxxx> writes: > I turned on all autovacuum logging and cranked up the test script and > have it fork 25 consumers each running 25 iterations. At that level > on my machine I can get the lock waiting to exceed the 1s > deadlock_timeout right away but the autovacuum activity on > pg_listener is entirely absent until the end when the forked > consumers are mostly done and disconnected. Hmph. At 25/100 I can get a few complaints about NOTIFY taking more than 20ms, but it seems to be due to blocking behind autovacuum, as in this example: 2008-02-25 14:53:41.812 EST 13773 LOG: automatic vacuum of table "joels.pg_catalog.pg_listener": index scans: 0 pages: 0 removed, 78 remain tuples: 5560 removed, 25 remain system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec 2008-02-25 14:53:41.850 EST 13773 LOG: automatic analyze of table "joels.pg_catalog.pg_listener" system usage: CPU 0.00s/0.00u sec elapsed 0.03 sec 2008-02-25 14:53:41.851 EST 13728 LOG: duration: 29.270 ms statement: NOTIFY to_producer 2008-02-25 14:53:41.852 EST 13758 LOG: duration: 22.835 ms statement: NOTIFY to_producer It's weird that the behavior is robust for you but I can't make it happen at all. Would you show the output of pg_config, as well as all your nondefault postgresql.conf settings? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
