Re: Streaming replication, loose ends

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Streaming replication, loose ends
Дата
Msg-id 4B509C30.2070300@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Streaming replication, loose ends  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Streaming replication, loose ends  (Robert Haas <robertmhaas@gmail.com>)
Re: Streaming replication, loose ends  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Yep. What's happening is that "make -j" starts building libpq and
>> walreceiver.so simultaneously, because of the above line in the
>> Makefile. We actually have the same problem in src/bin/*/Makefile, but
>> we don't notice it there because src/interfaces is listed before src/bin
>> in src/Makefile, so when you do "make -j" at the top-level, libpq is
>> built first.
> 
> I'm actually fairly uncomfortable with the notion that something buried
> deep within the src/backend tree is going to reach over and cause libpq
> to get built.  Maybe the real answer is that you put walreceiver in the
> wrong place, and it ought to be under src/bin/.

That feels even more wrong to me. Walreceiver is a postmaster
subprocess, tightly integrated with the rest of the backend.

One can argue that it shouldn't be, and walreceiver process should call
libpq through some new API, and the builtin implementation of that API
which uses libpq would be a loadable module that could be in src/bin/ or
contrib. Greg Stark requested that earlier. But I don't want to start
designing such an API at this point.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: New XLOG record indicating WAL-skipping
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Streaming replication status