On Thu, Nov 12, 2009 at 2:12 AM, Andrew Gierth <and...@tao11.riddles.org.uk> wrote: > Does it cope with the case where a trigger is doing NOTIFY, and you do > a whole-table update, therefore dumping potentially millions of > notifications in at once? > > (for example a rare maintenance operation on a table which has a > listen/notify arrangement triggered by single inserts or updates) > > The existing implementation copes with that just fine.
As long as you use the existing way to send out notifications by just sending "NOTIFY foo", then yes, it will cope with millions of them just fine because it will collapse them into one notification as does the current implementation (contrary to the current implementation a notification will be received from every transaction that has sent one - the current implementation even collapses notifications from different transactions). However if you decide to use the new syntax and add a distinct payload to every NOTIFY, then you also send out millions of notifications... With the proposed patch the queue has space for up to about 81,787,680 notifications. The limits are mainly imposed by slru.c which defines page size, pages per segment and the number of segments available. We could easily bump that up to a multiple of the current limits if we have decided that we need to... Joachim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers