Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Andrew Chernow wrote:
> >>> Tom Lane wrote:
> Andrew Chernow writes:
> > I can try. Where should this be documented? ISTM that the best
> > place is at the top of "30.1 Database Connection Control Functions
Bruce Momjian wrote:
Andrew Chernow wrote:
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow writes:
I can try. Where should this be documented? ISTM that the best
place is at the top of "30.1 Database Connection Control Functions",
since the issue pertains to any connect/disconnect fu
Andrew Chernow wrote:
> Andrew Chernow wrote:
> > Tom Lane wrote:
> >> Andrew Chernow writes:
> >>> I can try. Where should this be documented? ISTM that the best
> >>> place is at the top of "30.1 Database Connection Control Functions",
> >>> since the issue pertains to any connect/disconnect
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow writes:
I can try. Where should this be documented? ISTM that the best
place is at the top of "30.1 Database Connection Control Functions",
since the issue pertains to any connect/disconnect function. Does
that sound correct? Should it
Tom Lane wrote:
Andrew Chernow writes:
I can try. Where should this be documented? ISTM that the best place
is at the top of "30.1 Database Connection Control Functions", since the
issue pertains to any connect/disconnect function. Does that sound
correct? Should it be a warning or just r
Andrew Chernow writes:
> I can try. Where should this be documented? ISTM that the best place
> is at the top of "30.1 Database Connection Control Functions", since the
> issue pertains to any connect/disconnect function. Does that sound
> correct? Should it be a warning or just regular tex
Magnus Hagander wrote:
Andrew Chernow wrote:
Magnus Hagander wrote:
In which case, we should perhaps just document the workaround using
WSAStartup() yourself, and not bother with either API or connection
parameter...
I didn't originally agree with this but now I do. Any libpq init
function
Andrew Chernow wrote:
> Magnus Hagander wrote:
>>
>> In which case, we should perhaps just document the workaround using
>> WSAStartup() yourself, and not bother with either API or connection
>> parameter...
>>
>>
>
> I didn't originally agree with this but now I do. Any libpq init
> function for
Magnus Hagander wrote:
In which case, we should perhaps just document the workaround using
WSAStartup() yourself, and not bother with either API or connection
parameter...
I didn't originally agree with this but now I do. Any libpq init function for
wsa, would only be replacing an app call
James Mansion wrote:
> Andrew Chernow wrote:
>> The only problem is how to detect the first connection. In a threaded
>> environment you'd have to perform locking in connectdb, which is
>> probably not going to fly.
> Well, if you do an atomic test for a flag being zero, and if so then
> enter a c
Andrew Chernow wrote:
The only problem is how to detect the first connection. In a threaded
environment you'd have to perform locking in connectdb, which is
probably not going to fly.
Well, if you do an atomic test for a flag being zero, and if so then
enter a critsec, do
the init iff you're t
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>> Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Ah, OK, so it does its own cleanup on last close, great. I agree a
> > connection option for this would be good.
> >
> What w
Bruce Momjian wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>> Ah, OK, so it does its own cleanup on last close, great. I agree a
> >>> connection option for this would be good.
> >>>
> >> What would the option be? "wsainit = [enable | disable]"? Maybe it
Andrew Dunstan wrote:
>
>
> Andrew Chernow wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>>
> >>> Ah, OK, so it does its own cleanup on last close, great. I agree a
> >>> connection option for this would be good.
> >>>
> >>
> >> What would the option be? "wsainit = [enable | disa
Bruce Momjian wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "wsa_vers
Andrew Chernow wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "ws
Andrew Chernow wrote:
> Bruce Momjian wrote:
> >
> > Ah, OK, so it does its own cleanup on last close, great. I agree a
> > connection option for this would be good.
> >
>
> What would the option be? "wsainit = [enable | disable]"? Maybe it
> should allow setting the version to load: "wsa_ver
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "wsa_version = 2.0". Maybe
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "wsa_version = 2.0". Maybe
the two should be comb
Jeroen Vermeulen wrote:
Would there be any serious harm in:
1. doing the WSAStartup() when the first connection is opened, but
The only problem is how to detect the first connection. In a threaded
environment you'd have to perform locking in connectdb, which is
probably not going to fly.
Merlin Moncure wrote:
I think init/uninit is the answer. While writing libpqtypes, we noted
that libpq is just plain awkward in a few different ways and probably
deserves a rewrite at some point. not today though
Would there be any serious harm in:
1. doing the WSAStartup() when the fir
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>> We could have gone with a more elegant init/uninit solution but there is
> >>> a history of slow upstream adoption of libpq API changes.
> >>>
> >>>
> >> If that's the case, adding a connectdb op
Bruce Momjian wrote:
> Andrew Chernow wrote:
>> Bruce Momjian wrote:
>>> We could have gone with a more elegant init/uninit solution but there is
>>> a history of slow upstream adoption of libpq API changes.
>>>
>>>
>> If that's the case, adding a connectdb option seems like a good
>> alternative.
Andrew Chernow wrote:
> Bruce Momjian wrote:
> >
> > We could have gone with a more elegant init/uninit solution but there is
> > a history of slow upstream adoption of libpq API changes.
> >
> >
>
> If that's the case, adding a connectdb option seems like a good
> alternative. Orignally sugg
Bruce Momjian wrote:
We could have gone with a more elegant init/uninit solution but there is
a history of slow upstream adoption of libpq API changes.
If that's the case, adding a connectdb option seems like a good
alternative. Orignally suggested here:
http://archives.postgresql.org/pg
James Mansion wrote:
> Magnus Hagander wrote:
> > The use-case of rapidly creating and dropping connections isn't
> > particularly common, I think. And there is a perfectly functioning
> > workaround - something that we should perhaps document in the FAQ or
> > somewhere in the documentation?
> >
>
Magnus Hagander wrote:
Andrew Chernow wrote:
James Mansion wrote:
Is there a need for a new API to control this - can't you just
interpret another parameter keyword
in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)?
That's an interesting idea. I don't know if its the correct
Andrew Chernow wrote:
> James Mansion wrote:
>> Is there a need for a new API to control this - can't you just
>> interpret another parameter keyword
>> in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)?
>
> That's an interesting idea. I don't know if its the correct place to
> c
James Mansion wrote:
Is there a need for a new API to control this - can't you just interpret
another parameter keyword
in PQconnectdb (or the pgoptions string in PQsetdbLogin I guess)?
That's an interesting idea. I don't know if its the correct place to control
this, but it does allow turn
James Mansion wrote:
> Andrew Chernow wrote:
>> m$ docs indicate that wsastartup can't be called from dllmain :(
>>
> OK, fair cop. Says it in the MSDN online version but not in the SDK 6.1
> version. :-( Some helper(s)
> must start threads I guess.
That, and it loads other DLLs as well.
> Re
Andrew Chernow wrote:
m$ docs indicate that wsastartup can't be called from dllmain :(
OK, fair cop. Says it in the MSDN online version but not in the SDK 6.1
version. :-( Some helper(s)
must start threads I guess.
Re the counting and doing it on first/last socket - of course WSAStartup
co
James Mansion wrote:
If you have a DLL for libpq, could you do it in process attach and
detach? Wouldn't
that be the most common case anyway?
m$ docs indicate that wsastartup can't be called from dllmain :(
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
Magnus Hagander wrote:
The use-case of rapidly creating and dropping connections isn't
particularly common, I think. And there is a perfectly functioning
workaround - something that we should perhaps document in the FAQ or
somewhere in the documentation?
Would it be accetable to do initialise
Personally, I don't think its the job of libpq to call wsa startup or
shutdown. Pulling it out now will surely break existing apps and piss
I'm afraid it is. Looking at the API docs, the very first paragraph says:
"The WSAStartup function must be the first Windows Sockets function
called by an
Tom Lane wrote:
Magnus Hagander writes:
Yeah. So the question is, do we want to bite the bullet and create
init() and uninit() functions for libpq?
I think if calling them is an optimization that improves performance
(by eliminating per-connection-start overhead), this could fly. If
the plan
Magnus Hagander writes:
> Yeah. So the question is, do we want to bite the bullet and create
> init() and uninit() functions for libpq?
I think if calling them is an optimization that improves performance
(by eliminating per-connection-start overhead), this could fly. If
the plan is "we are goin
Andrew Chernow wrote:
> Magnus Hagander wrote:
>> Andrew Chernow wrote:
>>> WSACleanup is not really needed during a PQfinish. Its horribly slow if
>>> the library ref count is 0 and it actually unloads the winsock library,
>>> adds 225ms to PQfinish.
>>>
>>> Solution:
>>> A) Call WSAStartup once
Tom Lane wrote:
> Alvaro Herrera writes:
>> Magnus Hagander wrote:
>>> If you want to override this behavior today, you can just call
>>> WSAStartup() in your application, and it should never happen. Right?
>
>> Or perhaps use _init() and _fini() or the Win32 equivalents?
>
> I thought we were a
Alvaro Herrera writes:
> Magnus Hagander wrote:
>> If you want to override this behavior today, you can just call
>> WSAStartup() in your application, and it should never happen. Right?
> Or perhaps use _init() and _fini() or the Win32 equivalents?
I thought we were already relying on DLL load/u
On 1/16/09, Magnus Hagander wrote:
> Andrew Chernow wrote:
> > WSACleanup is not really needed during a PQfinish. Its horribly slow if
> > the library ref count is 0 and it actually unloads the winsock library,
> > adds 225ms to PQfinish.
>
> Option A will make us leak the reference to it tho
Alvaro Herrera wrote:
Magnus Hagander wrote:
Andrew Chernow wrote:
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock library,
adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up.
Alvaro Herrera wrote:
> Magnus Hagander wrote:
>> Andrew Chernow wrote:
>>> WSACleanup is not really needed during a PQfinish. Its horribly slow if
>>> the library ref count is 0 and it actually unloads the winsock library,
>>> adds 225ms to PQfinish.
>>>
>>> Solution:
>>> A) Call WSAStartup once
Magnus Hagander wrote:
> Andrew Chernow wrote:
> > WSACleanup is not really needed during a PQfinish. Its horribly slow if
> > the library ref count is 0 and it actually unloads the winsock library,
> > adds 225ms to PQfinish.
> >
> > Solution:
> > A) Call WSAStartup once and never clean it up.
Magnus Hagander wrote:
Andrew Chernow wrote:
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock library,
adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up. When the app dies, so
Andrew Chernow wrote:
> WSACleanup is not really needed during a PQfinish. Its horribly slow if
> the library ref count is 0 and it actually unloads the winsock library,
> adds 225ms to PQfinish.
>
> Solution:
> A) Call WSAStartup once and never clean it up. When the app dies, so do
> the ref c
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock
library, adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up. When the app dies, so do
the ref counts and winsock is automatical
WSACleanup is not really needed during a PQfinish. Its horribly slow if
the library ref count is 0 and it actually unloads the winsock
library, adds 225ms to PQfinish.
Solution:
A) Call WSAStartup once and never clean it up. When the app dies, so do
the ref counts and winsock is automatical
48 matches
Mail list logo
