Heikki Linnakangas <heikki.linnakan...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
