Re: walreceiver is uninterruptible on win32

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: walreceiver is uninterruptible on win32
Date: 2010-04-12 16:56:51
Message-ID: x2y9837222c1004120956zef64d9esf766e3f0fa247a03@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 12, 2010 at 13:54, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Apr 8, 2010 at 5:01 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> If it does, there should be
>>> some way to get PGXS to execute that rule as well, I'm sure.
>>
>> If we can copy/link the source file defining "new PQexec" when
>> we compile the dblink, DLL doesn't seem to be required. So I
>> stop creating new DLL for PGXS.
>
> On second thought, ISTM that we cannot use any source files which exist
> in places other than contrib/dblink and installation directory when we
> compile dblink under USE_PGXS=1. But we can put the file implementing
> new PQexec on those neither. So I'm thinking again that it should be
> provided as the shared library and be linked from walreceiver and dblink.
> Is this right?
>
> If adding new shared library is too big change at this point, I think
> that we should postpone the fix only for dblink to 9.1 or later. Since
> no one has complained about this long-term problem of dblink, I'm not
> sure it really should be fixed right now. Thought?

+1. Let's fix walreceiver for now, and we can revisit dblink later.
Since we haven't had any complaints so far...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-04-12 17:50:46 Re: GSoC - proposal - Materialized Views in PostgreSQL
Previous Message Jaime Casanova 2010-04-12 16:27:56 Re: testing hot standby