Re: [HACKERS] Time to fix libpgtcl for async NOTIFY

Поиск
Список
Период
Сортировка
От Massimo Dal Zotto
Тема Re: [HACKERS] Time to fix libpgtcl for async NOTIFY
Дата
Msg-id 199805262136.XAA00737@nikita.wizard.it
обсуждение исходный текст
Ответ на Re: [HACKERS] Time to fix libpgtcl for async NOTIFY  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] Time to fix libpgtcl for async NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>
> > There's some risk of breaking existing applications, since the apps
> > might not be prepared for pg_listen callbacks occurring except at the
> > specific time they execute pg_notifies.  But that doesn't seem really
> > likely to be a problem.  Besides, since both these commands are
> > undocumented, I imagine not very many libpgtcl applications use them.
> > (A quick search of the archives turned up only a message from Massimo
> > Dal Zotto about this topic, and he seemed to agree that getting rid of
> > pg_notifies would be better.)
> >
> > Any comments?
>
> Yep, get rid of the old stuff.  I am sure people didn't use it because
> of the performance problem.  Your cleanup will make it use-able.
>
> --
> Bruce Momjian                          |  830 Blythe Avenue
> maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
>   +  If your life is a hard drive,     |  (610) 353-9879(w)
>   +  Christ can be your backup.        |  (610) 853-3000(h)
>

The old stuff works fine, at least for me!

I'm using it, and my users like it very much. It suffers of performance
problems but they are caused by bottlenecks on pg_listener and not by
the pg_notifies loop in tcl (wich is done every 1 second by 30+ clients).
I'm probably the only one who uses this feature, partly because I never
found the time to write down some documentation about it (my fault), so
any change you make shouldn't break many applications.

If you are making changes to the tcl listen code please consider adding the
following missing feature:

- the possibility to temporarily suspend callbacks for a particular listen
  or for all listens. This would help to avoid the above possible problem.
  I currently do it with ad-hoc code in the application but having it done
  by a single call to libpgtcl would be better.

- an option to get the callback associated to a particular listen or to all
  listens

- better support for unlistening. There is an unlisten function in my
  contrib code but it should be integrated into the backend with a real
  UNLISTEN command.

--
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto                e-mail:  dz@cs.unitn.it            |
|  Via Marconi, 141                 phone:  ++39-461-534251            |
|  38057 Pergine Valsugana (TN)     www:  http://www.cs.unitn.it/~dz/  |
|  Italy                            pgp:  finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Query cancel and OOB data (fwd)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Query cancel and OOB data (fwd)