Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication, loose ends

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, loose ends
Date: 2010-01-15 16:47:44
Message-ID: 4B509C30.2070300@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

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

In response to

Responses

pgsql-hackers by date

Next:From: Greg SmithDate: 2010-01-15 16:50:39
Subject: Re: Streaming replication status
Previous:From: Simon RiggsDate: 2010-01-15 16:45:56
Subject: Hot Standby and handling max_standby_delay

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group