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. 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]
"C:\postgresql\pgsql.sln" (default target) (1) ->
"C:\postgresql\worker_spi.vcxproj" (default target) (77) -> worker_spi.obj : error LNK2001: unresolved external symbol
UnBlockSig
[C:\pos
tgresql\worker_spi.vcxproj] .\Release\worker_spi\worker_spi.dll : fatal error LNK1120: 1
unresolved externals [C:\postgresql\worker_spi.vcxproj]
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.
Oh, and this needs docs.
- Heikki