Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> On 13.06.2012 14:28, Andres Freund wrote:
>> A logical WALReceiver is started directly by Postmaster when we
>> enter PM_RUN state and the new parameter multimaster_conninfo is
>> set. For now only one of those is started, but the code doesn't
>> rely on that. In future multiple ones should be allowed.
> In general, I feel that the receiver-side could live outside core.
> The sender-side needs to be at least somewhat integrated into the
> walsender stuff, and there are changes to the WAL records etc.
> that are hard to do outside, but AFAICS the stuff to receive
> changes is pretty high-level stuff.
It would be nice if there was at least a thin layer of the sender
portion which could by used by a stand-alone program. I can think
of lots of useful reasons to "T" the WAL stream -- passing through
the stream with little or no modification to at least one side. As
just one example, I would like a program to write traditional WAL
files to match what an archive on the sending side would look like
while passing the stream through to an asynchronous hot standby.
> As long as the protocol between the logical replication client
> and server is well-defined, it should be possible to write all
> kinds of clients. You could replay the changes to a MySQL database
> instead of PostgreSQL, for example, or send them to a message
> queue, or just log them to a log file for auditing purposes. None
> of that needs to be in implemented inside a PostgreSQL server.
+1
-Kevin