Re: Streaming replication, loose ends

On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Tom Lane wrote:
>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.

The major problem with having one part of the tree depend on a
completely different part of the tree is that it's easy for the
dependencies to be wrong. If the backend depends on libpq, then it
depends implicitly on all the things on which libpq depends. If
something that libpq depends on, but that the backend does not depend
on directly, gets updated, does the backend get rebuilt? It's easy to
get this wrong. On the other hand, it's also possible to get it
right. If we can decide what we want to happen, I'm willing to take a
crack at it, though if you or Tom or Peter prefer to do it that is
certainly OK with me too.

...Robert