Re: Streaming replication and non-blocking I/O - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Streaming replication and non-blocking I/O
Date
Msg-id 18174.1261419688@sss.pgh.pa.us
Whole thread Raw
In response to Re: Streaming replication and non-blocking I/O  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Fujii Masao wrote:
> 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.

From a packager's standpoint the second is much saner.  If you want to
use dlopen() then you will have to know the exact name of the .so file
(e.g. libpq.so.5.3) and possibly its location too.  Or you will have to
persuade packagers that they should ship bare "libpq.so" symlinks, which
is contrary to packaging standards on most Linux distros.
(walreceiver.so wouldn't be subject to those standards, but libpq is
because it's a regular library that can also be hard-linked by
applications.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Table size does not include toast size
Next
From: "David E. Wheeler"
Date:
Subject: Segfault from PL/Perl Returning vstring