Fujii Masao wrote:
> On Tue, Dec 22, 2009 at 2:31 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> 2. Move walreceiver altogether into a loadable module, which is linked
>> as usual to libpq. Like e.g contrib/dblink.
>>
>> Thoughts? Both seem reasonable to me. I tested the 2nd option (see
>> 'replication' branch in my git repository), splitting walreceiver.c into
>> two: the functions that run in the walreceiver process, and the
>> functions that are called from other processes to control walreceiver.
>> That's a quite nice separation, though of course we could do that with
>> the 1st approach as well.
>
> Though I seem not to understand what a loadable module means, I wonder
> how the walreceiver module is loaded. AFAIK, we need to manually install
> the dblink functions by executing dblink.sql before using them. Likewise,
> if we choose the 2nd option, we must manually install the walreceiver
> module before starting replication?
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.
shared_preload_libraries seems like a bad place because the library
doesn't need to be loaded in all backends. Just the walreceiver process.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
