Heikki Linnakangas escribió:
> On 23.10.2012 00:29, Alvaro Herrera wrote:
> >Here's an updated version of this patch, which also works in
> >an EXEC_BACKEND environment. (I haven't tested this at all on Windows,
> >but I don't see anything that would create a portability problem there.)
>
> Looks good at first glance.
Thanks.
> Fails on Windows, though:
>
> "C:\postgresql\pgsql.sln" (default target) (1) ->
> "C:\postgresql\auth_counter.vcxproj" (default target) (29) ->
> (Link target) ->
> auth_counter.obj : error LNK2001: unresolved external symbol
> UnBlockSig [C:\p
> ostgresql\auth_counter.vcxproj]
> .\Release\auth_counter\auth_counter.dll : fatal error LNK1120: 1
> unresolved externals [C:\postgresql\auth_counter.vcxproj]
Wow. If that's the only problem it has on Windows, I am extremely
pleased.
Were you able to test the provided test modules? Only now I realise
that they aren't very friendly because there's a hardcoded database name
in there ("alvherre", not the wisest choice I guess), but they should at
least be able to run and not turn into a fork bomb due to being unable
to connect, for instance.
> Marking UnBlockSig with PGDLLIMPORT fixes that. But I wonder if it's
> a good idea to leave unblocking signals the responsibility of the
> user code in the first place? That seems like the kind of low-level
> stuff that you want to hide from extension writers.
Sounds sensible.
I am unsure about the amount of pre-cooked stuff we need to provide.
For instance, do we want some easy way to let the user code run
transactions?
> Oh, and this needs docs.
Hmm, yes it does.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
