Joel Stevenson <[EMAIL PROTECTED]> 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
