Re: Streaming replication and non-blocking I/O

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and non-blocking I/O
Date: 2009-12-22 11:49:14
Message-ID: 4B30B23A.3080605@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao wrote:
> On Tue, Dec 22, 2009 at 3:30 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-12-22 12:16:38 Re: Tuplestore should remember the memory context it's created in
Previous Message Heikki Linnakangas 2009-12-22 11:45:50 Tuplestore should remember the memory context it's created in