Re: Streaming replication and non-blocking I/O - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Streaming replication and non-blocking I/O
Date
Msg-id 4B30B23A.3080605@enterprisedb.com
Whole thread Raw
In response to Re: Streaming replication and non-blocking I/O  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Streaming replication and non-blocking I/O  (Fujii Masao <masao.fujii@gmail.com>)
Re: Streaming replication and non-blocking I/O  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao wrote:
> On Tue, Dec 22, 2009 at 3:30 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> I think we can just use load_external_function() to load the library and
>> call WalReceiverMain from AuxiliaryProcessMain(). Ie. hard-code the
>> library name. Walreceiver is quite tightly coupled with the rest of the
>> backend anyway, so I don't think we need to come up with a pluggable API
>> at the moment.
>>
>> That's the way I did it yesterday, see 'replication' branch in my git
>> repository, but it looks like I fumbled the commit so that some of the
>> changes were committed as part of the merge commit with origin/master
>> (=CVS HEAD). Sorry about that.
> 
> Umm.., I still cannot find the place where the walreceiver module is
> loaded by using load_external_function() in your 'replication' branch.
> Also the compilation of that branch fails. Is the 'pushed' branch the
> latest? Sorry if I'm missing something.

Ah, I see. The changes were not included in the merge commit after all,
but I had simple forgot to "git add" them. Sorry about that, should be
there now.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Tuplestore should remember the memory context it's created in
Next
From: Greg Stark
Date:
Subject: Re: Tuplestore should remember the memory context it's created in