Fujii Masao wrote: > On Tue, Dec 22, 2009 at 2:31 AM, Heikki Linnakangas > <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
