> Hm. To me it looks like the first psql session isn't prepared to gather
> async notifies (checking...) indeed, psql only checks for async notifies when
> issuing commands (you don't have to issue a NOTIFY in "Connection 1" to
> receive the pending notifies -- *any* request directed to the server would do).
>
> If you see the queue building up as above, the problem lies almost
> certainly on the client not gathering the notifies. The backend is
> obviously willing to talk to you :-)
>
> I'd look for the problem in the client library (It's DBD::Pg in your
> "real" case, isn't it?)

*Light bulb lights up* Ah....I see what's going on now.

I think I have enough information to test and fix the problem on our
end. Thank you all for your help and patience. This can be considered
resolved.

Peter

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

> Please share the ending with us, I'm really curious after following this
> thread .

It turns out that it was part DBD::Pg and part our app (a big part). A
plugin for the app creates a separate db handle which listens, but
never does anything with the notifications. Apparently, the recv-q
cleared whenever a request was made via this plugin (which is rare for
most people who use this), but nothing was processed, so notifications
would build up. If they're left running for that long, then they get
into the bad state.

We fixed our app to not have the plugin's db handle listen (it was
pointless to have it listen anyway) and all seems well.

While it may technically be a bug that a database handle will get into
this state after ~800 unprocessed notifications, I'd say that's much
more the fault of the application programmers.

Anyway, thanks for all your help.

Peter

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq