Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender
От | Heikki Linnakangas |
---|---|
Тема | Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender |
Дата | |
Msg-id | 4FEDC6BB.2030900@enterprisedb.com обсуждение исходный текст |
Ответ на | [PATCH 13/16] Introduction of pair of logical walreceiver/sender (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PATCH 13/16] Introduction of pair of logical
walreceiver/sender
Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender |
Список | pgsql-hackers |
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. Could the receiver-side of this be handled as an extra daemon: http://archives.postgresql.org/message-id/CADyhKSW2uyrO3zx-tohzRhN5-vaBEfKNHyvLG1yp7=cx_YH9UA@mail.gmail.com 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. 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: