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? Or we automatically install that by executing system_view.sql, like pg_start_backup? I'd like to reduce the number of installation operations as much as possible. Is my concern besides the point? > PS. I just merged with CVS HEAD. Streaming replication is pretty awesome > with Hot Standby! Thanks! Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers