Fujii Masao wrote:
> On Tue, Dec 15, 2009 at 4:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm. Perhaps it should be a loadable plugin and not hard-linked into the
>> backend? Compare dblink.
>
> You mean that such plugin is supplied in shared_preload_libraries,
> a new process is forked and the shared-memory related to walreceiver
> is created by using shmem_startup_hook? Since this approach would
> solve the problem discussed previously, ISTM this makes sense.
> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00031.php
>
> Some additional code might be required to control the termination
> of walreceiver.
I'm not sure which problem in that thread you're referring to, but I can
see two options:
1. Use dlopen()/dlsym() in walreceiver to use libpq. A bit awkward,
though we could write a bunch of macros to hide that and make the libpq
calls look normal.
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.
PS. I just merged with CVS HEAD. Streaming replication is pretty awesome
with Hot Standby!
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
