Re: Streaming replication and non-blocking I/O

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Streaming replication and non-blocking I/O
Дата
Msg-id 18174.1261419688@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Streaming replication and non-blocking I/O  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Table size does not include toast size
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Segfault from PL/Perl Returning vstring