People have always expressed interest in $subject, so I wondered how
hard it could possibly be and came up with the attached patch.
Notifications that are generated on the master and are forwarded to
the standby can be used as a convenient way to find out which changes
have already made it to the standby. The idea would be that you run a
transaction on the master, add a "NOTIFY changes_made", and listen on
the standby for this event. Once it gets delivered, you know that your
transaction got replayed to the standby.
Note that this feature is only about LISTEN on the standby, it still
doesn't allow sending NOTIFYs out from the standby.
As a reminder, the current implementation of notifications
(LISTEN/NOTIFY) in a few words is:
- a transaction that executes "NOTIFY channel, payload" adds the
transaction to backend-local memory
- upon commit, it inserts the notifications along with its transaction
id into a large SLRU mapped ring buffer and signals any listening
backend
- each backend that's listening has a pointer into this ring buffer.
After each transaction, the backend starts reading from this pointer
position to the end of the ring buffer. It delivers all matching
notifications to its frontend if the transaction that has inserted
them is known to have committed.
In the patch I added a new WAL message type, XLOG_NOTIFY that writes
out WAL records when the notifications are written into the pages of
the SLRU ring buffer. Whenever an SLRU page is found to be full, a new
WAL record will be created, that's just a more or less arbitrary form
of batching a bunch of them together but that's easy to do and most
often, I think there won't be more than at most a few record per
transaction anyway.
The recovery process on the client side adds the notifications into
the standby's SLRU ring buffer and once the last notification has been
added (which might be after a couple more WAL records), it signals the
listening backends.
Theoretically we could also run into a full queue situation on the
standby: Imagine a long-running transaction doesn't advance its
pointer in the ring buffer and no new notifications can be stored in
the buffer. The patch introduces a new type of recovery conflict for
this reason.
One further optimization (that is not included for now) would be to
keep track of how many backends are actually listening on some channel
and if nobody is listening, discard incoming notifications.
