Re: Streaming replication and non-blocking I/O

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and non-blocking I/O
Date: 2010-01-15 21:47:18
Message-ID: 21219.1263592038@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Tom Lane wrote:
>> Specifically, I think you missed out $(BE_DLLLIBS) in SHLIB_LINK.
>> We'll find out at the next mingw build...

> Thanks. But what is BE_DLLLIBS? I can't find any description of it.

It was the wrong theory anyway --- it already is included (in
Makefile.shlib). But what it does is provide -lpostgres on platforms
where that is needed, such as mingw.

> I suspect the MinGW build will fail because of the missing PGDLLIMPORTs.

Yeah. On closer investigation the problem seems to be -DBUILDING_DLL,
which flips the meaning of PGDLLIMPORT. contrib/dblink, which surely
works and has the same linkage requirements as walreceiver, does *not*
use that. I've committed a patch to change that, we'll soon see if it
works...

> Before we sprinkle all the global variables it touches with that, let me
> explain what I meant by dividing walreceiver code differently between
> dynamically loaded module and backend code. Right now I have to go to
> sleep, though, but I'll try to get back to during the weekend.

Yeah, nothing to be done till we get another buildfarm cycle anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message J. Greg Davidson 2010-01-15 22:37:09 Re: xml2 still essential for us
Previous Message Kevin Grittner 2010-01-15 21:09:52 Re: Testing with concurrent sessions