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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
