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?
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