Re: walreceiver is uninterruptible on win32

On Tue, Apr 6, 2010 at 2:25 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Mon, Apr 5, 2010 at 3:18 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Fri, Apr 2, 2010 at 11:11 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>> More to the point, I'm not sure I like the creation of yet another DLL
>>> to deal with this. The reason this isn't just exported from the main
>>> backend is the same reason we created the libpqwalreceiver library I'm
>>> sure - bt that means we already have one.
>>>
>>> How about we just use this same source file, but compile and link it
>>> directly into both dblink and libpqwalreceiver? That'd leave us with
>>> one DLL less, making life easier.
>>
>> ISTM that we cannot compile dblink using USE_PGXS=1, if that DLL doesn't
>> exist in the installation directory. No?
>
> I might have misinterpreted your point. You mean that the same source
> file defining something like pgwin32_PQexec should be placed in both
> contrib/dblink and src/backend/replication/libpqwalreceiver? If so,
> we can compile dblink using USE_PGXS without the DLL.

No, I don't mean that. I mean store it in one place, and copy/link it
into where it's used. Look at for example how crypt.c and
getaddrinfo.c are handled in libpq.

Not sure how that will play with PGXS, though, but I'm not entirely
sure we care if it can be built that way? If it does, there should be
some way to get PGXS to execute that rule as well, I'm sure.

Also note that per Tom's comments this is not a win32 only fix, so it
shouldn't be called pgwin32_*().

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