Re: pg_listening_channels() - Mailing list pgsql-general

From Tom Lane
Subject Re: pg_listening_channels()
Date
Msg-id 16375.1354220219@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_listening_channels()  (Igor Neyman <ineyman@perceptron.com>)
List pgsql-general
Igor Neyman <ineyman@perceptron.com> writes:
>> [ shrug... ] It was debated extensively and the advantages of the new
>> implementation were deemed to outweigh the disadvantages.

> Are you saying that these two features: attached payload and being able to find which channels are being listened to
-are incompatible?  That they cannot coexist? 

It's not about the payload aspect.  We got rid of the use of a table to
store messages-in-transit, which resulted in greatly improved throughput
and lower overhead --- but it also means that there's no exposed
information about which backends are actually paying attention to
specific notify channels.  We could have bolted some overhead back on
to expose that again, but it was judged that too few people had that
requirement to justify imposing such overhead on everybody.  The
infrequency of complaints in the two years since then seems to justify
that choice.

It's not particularly difficult to create your own signaling system
for this purpose, if you think it's worth the trouble --- LISTEN just
doesn't have it built in anymore.  In practice, I'll bet it's not worth
the trouble versus just firing off messages unconditionally.

            regards, tom lane


pgsql-general by date:

Previous
From: Stefan Keller
Date:
Subject: Storing files in the database - and giving easy access to this?
Next
From: Mike Blackwell
Date:
Subject: Enforcing minimum on many-to-many relationship?