Re: walreceiver is uninterruptible on win32 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: walreceiver is uninterruptible on win32
Date
Msg-id y2u3f0b79eb1004120454lde94595cldf5521a6a9b8fab@mail.gmail.com
Whole thread Raw
In response to Re: walreceiver is uninterruptible on win32  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: walreceiver is uninterruptible on win32  (Joseph Conway <mail@joeconway.com>)
Re: walreceiver is uninterruptible on win32  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Thu, Apr 8, 2010 at 5:01 PM, Fujii Masao <masao.fujii@gmail.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?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: testing HS/SR - 1 vs 2 performance
Next
From: "Erik Rijkers"
Date:
Subject: Re: testing HS/SR - 1 vs 2 performance