On Friday, June 29, 2012 05:16:11 PM Heikki Linnakangas 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.
> Could the receiver-side of this be handled as an extra daemon:
Well, I think it depends on what the protocol turns out to be. In the
prototype we used the infrastructure from walreceiver which reduced the
required code considerably.
> In general, I feel that the receiver-side could live outside core.
I think it should be possible to write receivers outside core, but one
sensible implementation should be in-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
> None of that needs to be in implemented inside a PostgreSQL server.
If you want robust and low-overhead crash recovery you need (at least I think
so) tighter integration into postgres. To be sure that you pick of where you
stopped after a crash you need to have a state synchronized to the commits
into the receiving side. So you either always write to another table and
analyze that afterwards - which imo sucks - or you integrate it with the
commit record. Which needs integration into pg.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2012-06-29 15:39:09|
|Subject: Re: [PATCH 13/16] Introduction of pair of logical walreceiver/sender|
|Previous:||From: Kevin Grittner||Date: 2012-06-29 15:28:16|
|Subject: Re: [PATCH 13/16] Introduction of pair of logical