| From: | Dave Page <dpage(at)postgresql(dot)org> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: notification payloads |
| Date: | 2007-03-26 18:41:15 |
| Message-ID: | 460813CB.8000908@postgresql.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
> No loss, but, per previous discussion, it would block and try to get
> other backends to collect their outstanding notifications.
>
> Let's say we provide 100Kb for this (which is not a heck of a lot) ,
> that the average notification might be, say, 40 bytes of name plus 60
> bytes of message. Then we have room for about 1000 messages in the
> queue. This would get ugly only if backend presumably in the middle of
> some very long transaction, refused to pick up its messages despite
> prodding. But ISTM that means we just need to pick a few strategic spots
> that will call CHECK_FOR_NOTIFICATIONS() even in the middle of a
> transaction and store them locally.
Sounds good.
Regards, Dave.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2007-03-26 18:56:37 | Re: Time to package 8.2.4 |
| Previous Message | Greg Sabino Mullane | 2007-03-26 18:40:13 | Re: Guarenteeing complex referencial integrity through custom triggers |