On Tue, Jan 10, 2012 at 12:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So this design is non-optimal both for existing uses and for the
> proposed new uses, which means nobody will like it. You could
> ameliorate #1 by adding a GUC that determines whether NOTIFY actually
> writes WAL, but that's pretty ugly. In any case ISTM that problem #2
> means this design is basically broken.
I chose to do it this way because it seemed like the most natural way
to do it (which of course doesn't mean it's the best) :-). I agree
that there should be a way to avoid the replication of the NOTIFYs.
Regarding your second point though, remember that on the master we
write notifications to the queue in pre-commit. And we also don't
interleave notifications of different transactions. So once the commit
record makes it to the standby, all the notifications are already
there, just as on the master. In a burst of notifications, both
solutions should more or less behave the same way but yes, the one
involving the WAL file would be slower as it goes to the file system
and back.
> I wonder whether it'd be practical to not involve WAL per se in this
> at all, but to transmit NOTIFY messages by having walsender processes
> follow the notify stream (as though they were listeners) and send the
> notify traffic as a separate message stream interleaved with the WAL
> traffic.
Agreed, having walsender/receiver work as NOTIFY proxies is kinda smart...
Joachim
