On Tue, Jan 10, 2012 at 12:00 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
