Re: fixing LISTEN/NOTIFY

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: fixing LISTEN/NOTIFY
Дата
Msg-id 63069.69.199.116.160.1128880539.squirrel@69.199.116.160
обсуждение исходный текст
Ответ на Re: fixing LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: fixing LISTEN/NOTIFY  (Josh Berkus <josh@agliodbs.com>)
Re: fixing LISTEN/NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane said:
> But I think you might be confusing that with the feature-or-bug
> (depending on one's point of view) that duplicate notifications can be
> merged into one event.  I'm inclined to preserve that behavior,
> primarily because not doing so would create a tremendous penalty on
> applications that expect it to work that way.

What sort of application are you envisioning?

If you mean there are applications for which avoiding duplicate
notifications is a performance win, I think those applications are on
shakey ground: the LISTEN/NOTIFY interface doesn't guarantee that no
duplicate notifications will be delivered (it merely doesn't guarantee
they *will* be delivered).

Personally, I think delivering all notifications by default is simpler
behavior for the application programmer to understand. If you want to
avoid doing work for duplicate notifications, you realistically need to
implement that yourself anyway.

-Neil




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: avoid pulling up subquerys that contain volatile functions?
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: fixing LISTEN/NOTIFY