Skip site navigation (1) Skip section navigation (2)

Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender
Date: 2012-06-29 15:16:11
Message-ID: 4FEDC6BB.2030900@enterprisedb.com (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2012-06-29 15:28:16
Subject: Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender
Previous:From: Boszormenyi ZoltanDate: 2012-06-29 15:02:08
Subject: Re: [v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group