Mirek Budzanowski <mirekb@tcs.uni.wroc.pl> writes:
> I got 2 proceses running on 2 different computers. One is Solaris
> 2.5.1 (a), the other HP-UX 10.20 (b). Postgres 6.4.2 ruuning on HP-UX.
> My proceses communicate with each other using postgres.
> They just do 'listen id', and the other send 'notify id'
> when is some data for the first.
> Both proceses wait on select() for notifies from the other.
Sounds fine --- my company's applications depend heavily on
LISTEN/NOTIFY, and it works perfectly reliably for us in 6.4.x.
(BTW, we are on HPUX too.)
> But after some time waiting on select() when i do from psql
> 'select * from pg_listener;' I get some strage result!
> Some times I get nothing, and some times only one proces!!
Not sure what is going on here. A LISTEN, once issued, is good for
the life of that backend (unless you UNLISTEN). I've never seen a
case of it getting dropped --- and our apps routinely run for weeks
and thousands of NOTIFY cycles.
The only thing I can think of offhand is that there are some
interactions between LISTEN/NOTIFY and transactions: if your app does
a LISTEN or a NOTIFY inside a transaction, the results will not be seen
elsewhere until you commit the transaction. Don't know if this applies
to your problem or not, but it's something to keep in mind when you use
NOTIFY.
I guess another obvious question is: are you sure you still have the
same backend as you originally issued the LISTEN to. PQreset(),
for example, kills the current backend and starts a new one. One
place this could be done without your realizing it is in a failed
COPY operation --- libpq uses PQreset() to recover if it loses sync
with the backend due to failure to follow the copy protocol...
regards, tom lane
