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

Re: Streaming replication and non-blocking I/O

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and non-blocking I/O
Date: 2010-01-15 20:19:54
Message-ID: 4B50CDEA.7080504@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Magnus Hagander wrote:
> 2010/1/15 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>>
>> Heikki Linnakangas wrote:
>>> Do people still use MinGW for any real work? Could we just drop
>>> walreceiver support from MinGW builds?
>>>
>>> Or maybe we should consider splitting walreceiver into two parts after
>>> all. Only the bare minimum that needs to access libpq would go into the
>>> shared object, and the rest would be linked with the backend as usual.
>>>
>> I use MinGW when doing Windows work (e.g. the threading piece in parallel pg_restore).  And I think it is generally desirable to be able to build on Windows using an open source tool chain. I'd want a damn good reason to abandon its use. And I don't like the idea of not supporting walreceiver on it either. Please find another solution if possible.
> 
> Yeah. FWIW, I don't use mingw do do any windows development, but
> definitely +1 on working hard to keep support for it if at all
> possible.

Ok. I'll look at splitting walreceiver code between the shared module
and backend binary slightly differently. At first glance, it doesn't
seem that hard after all, and will make the code more modular anyway.

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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-15 20:25:08
Subject: Re: Streaming replication and non-blocking I/O
Previous:From: Magnus HaganderDate: 2010-01-15 19:51:14
Subject: Re: Streaming replication and non-blocking I/O

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