Re: [HACKERS] Time to fix libpgtcl for async NOTIFY - Mailing list pgsql-hackers

From Massimo Dal Zotto
Subject Re: [HACKERS] Time to fix libpgtcl for async NOTIFY
Date
Msg-id 199805262136.XAA00737@nikita.wizard.it
Whole thread Raw
In response to Re: [HACKERS] Time to fix libpgtcl for async NOTIFY  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Time to fix libpgtcl for async NOTIFY  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Query cancel and OOB data (fwd)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Query cancel and OOB data (fwd)