Re: notification payloads

Поиск
Список
Период
Сортировка
Искать
От
Dave Page
Тема
Re: notification payloads
Дата
Msg-id
460813CB.8000908@postgresql.org
Ответ на
Re: notification payloads (Andrew Dunstan)
Список
Дерево обсуждения
notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Hannu Krosing <hannu@skype.net>
Re: notification payloads Hannu Krosing <hannu@skype.net>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Dave Page <dpage@postgresql.org>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Tom Lane <tgl@sss.pgh.pa.us>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Alvaro Herrera <alvherre@commandprompt.com>
Re: notification payloads Tom Lane <tgl@sss.pgh.pa.us>
Re: notification payloads Hannu Krosing <hannu@skype.net>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Hannu Krosing <hannu@skype.net>
Re: notification payloads Hannu Krosing <hannu@skype.net>
Re: notification payloads Tom Lane <tgl@sss.pgh.pa.us>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Tom Lane <tgl@sss.pgh.pa.us>
Re: notification payloads Heikki Linnakangas <heikki@enterprisedb.com>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads Dave Page <dpage@postgresql.org>
Re: notification payloads Gregory Stark <stark@enterprisedb.com>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
Re: notification payloads "Merlin Moncure" <mmoncure@gmail.com>
Re: notification payloads Andrew Dunstan <andrew@dunslane.net>
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.

В списке pgsql-hackers по дате отправления
От: Peter Eisentraut
Дата:
Сообщение: Re: Time to package 8.2.4
От: Dave Page
Дата:
Сообщение: Re: Time to package 8.2.4
FAQ