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.
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.
In response to
pgsql-hackers by date
|Next:||From: Greg Smith||Date: 2010-01-15 16:50:39|
|Subject: Re: Streaming replication status|
|Previous:||From: Simon Riggs||Date: 2010-01-15 16:45:56|
|Subject: Hot Standby and handling max_standby_delay|