Re: Listen / Notify rewrite

On Thu, Nov 12, 2009 at 2:12 AM, Andrew Gierth
<andrew(at)tao11(dot)riddles(dot)org(dot)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