Thread: Re: BUG #1545: LIBPQ Windows Version not calling WSACleanup for
>>> The only place WSACleanup is being called is libpqdll when=20 >the process >>> detaches the DLL (if the libpq is not staticly linked in),=20 >which matches up >>> with the WSAStartup when the process attaches to the DLL. >>>=20 >>> The WSAStartup in the fe-connect.c->makeEmptyPGconn() does=20 >not have a >>> matching WSACleanup. WSACleanup could possibly be placed=20 >in freePGconn(), >>> but unsure if all possible error cases will go through this=20 >function. >>>=20 >>> This problem exists in both 8.0.1 and 7.4.7 of the libpq=20 >interface for >>> Windows. > >> I agree freePGconn() is the proper place. I will apply the following >> patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I >> will wait for 8.0.4. > >Actually ... why do we need a WSAStartup in makeEmptyPGconn?=20=20 >If we have >one in DLL attach, isn't that sufficient? Not if you link libpq as a static lib... I *think* that's why it was added. In the beginning it was only in the DLL attach code, and if you were using the library as a static lib you had to call it yourself. Not sure when that changed, but clearly that is when the WSACleanup() call should've gone in. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
>> Actually ... why do we need a WSAStartup in makeEmptyPGconn?
>> If we have one in DLL attach, isn't that sufficient?
> Not if you link libpq as a static lib...
> I *think* that's why it was added. In the beginning it was only in the
> DLL attach code, and if you were using the library as a static lib you
> had to call it yourself. Not sure when that changed, but clearly that is
> when the WSACleanup() call should've gone in.
Ah. Makes sense. So adding it to freePGconn is correct.
Bruce, you should probably back-patch for as far as the WSAStartup call
is there, which looks to be 7.4.
regards, tom lane
Magnus Hagander wrote: > >>> The only place WSACleanup is being called is libpqdll when > >the process > >>> detaches the DLL (if the libpq is not staticly linked in), > >which matches up > >>> with the WSAStartup when the process attaches to the DLL. > >>> > >>> The WSAStartup in the fe-connect.c->makeEmptyPGconn() does > >not have a > >>> matching WSACleanup. WSACleanup could possibly be placed > >in freePGconn(), > >>> but unsure if all possible error cases will go through this > >function. > >>> > >>> This problem exists in both 8.0.1 and 7.4.7 of the libpq > >interface for > >>> Windows. > > > >> I agree freePGconn() is the proper place. I will apply the following > >> patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I > >> will wait for 8.0.4. > > > >Actually ... why do we need a WSAStartup in makeEmptyPGconn? > >If we have > >one in DLL attach, isn't that sufficient? > > Not if you link libpq as a static lib... > > I *think* that's why it was added. In the beginning it was only in the > DLL attach code, and if you were using the library as a static lib you > had to call it yourself. Not sure when that changed, but clearly that is > when the WSACleanup() call should've gone in. > OK, good. I will document that and have the fix in 8.0.4. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: > >> Actually ... why do we need a WSAStartup in makeEmptyPGconn? > >> If we have one in DLL attach, isn't that sufficient? > > > Not if you link libpq as a static lib... > > > I *think* that's why it was added. In the beginning it was only in the > > DLL attach code, and if you were using the library as a static lib you > > had to call it yourself. Not sure when that changed, but clearly that is > > when the WSACleanup() call should've gone in. > > Ah. Makes sense. So adding it to freePGconn is correct. > > Bruce, you should probably back-patch for as far as the WSAStartup call > is there, which looks to be 7.4. OK, going ahead. I am not thrilled to be fixing this so close to the release for untestable code. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073