Tom Lane wrote:
>The real problem I'm having with it is that I don't believe the
>use-case. The normal scenario for a listener is that you LISTEN and
>then you sit there waiting for events. In the above scenario, a client
>thread would only be able to receive events when it actively had control
>of its pool connection; so it seems like it would be at risk of missing
>things when it didn't. It seems much more likely that you'd design the
>application so that listening clients aren't pooled but are listening
>continuously.
I have an application that actually is able to install callbacks on one or more
of its pooled connections to wait for listens. However, the application is
not using this on the pooled connections because that would require one
to keep track of which connection the listen is registered on. It would
require that that connection is never closed.
Instead of keeping track of this fact, I'd presume that it'd be easier to
simply group all listens on a single connection outside the pool. So your
patch will not benefit any practical use cases I can think of.
--
Sincerely, Stephen R. van den Berg.