Re: Streaming replication, loose ends

Robert Haas wrote:
> 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?

The backend doesn't get rebuilt, and it doesn't need to be. The fact
that walreceiver is a dynamically loaded module should isolate changes
in libpq or its dependencies from affecting the rest of the backend.

I moved the line for src/backend/replication/walreceiver in src/Makefile
further down, after src/interfaces. That should fix the build failures
for now, but I'm all ears if there's better suggestions.

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