Fujii Masao wrote: > On Tue, Dec 15, 2009 at 4:11 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
