On Wed, Oct 5, 2011 at 09:24, Craig Ringer <ringerc@ringerc.id.au> wrote:
> Tom Lane wrote:
>>
>> However, the flaw in that explanation is that it would basically mean
>> pg_dump doesn't work at all on Windows, at least not if you have any
>> user-defined functions, and probably some other cases too because there
>> seem to be multiple instances of the dubious coding. =A0It's a bit hard =
to
>> believe that nobody's noticed that before.
>
> It's like a double-free - you often get away with it. Some people will ne=
ver
> notice it. Others will crash on it consistently. It'll crash for some peo=
ple
> only on tuesday evenings on full moons, but only if they're in the southe=
rn
> hemisphere and using a laptop with an exactly 1.8GHz CPU. Etc.
>
> Add the "interesting" variety of Windows environments and configurations
> that exist and it's not surprising to see this sort of issue pop up only
> occasionally.
>
> In particular, if your libpq and pg_dump link to the exact same msvcrt *a=
nd*
> that's a dynamic (dll) runtime not a static runtime, you'll get away with
> this. If they link to the same static runtime it'll crash. If they link to
> different dynamic runtimes - different versions, different thread/debug
> options, etc - then you still might get away with it or might not, depend=
ing
> on the usual luck associated with double free issues.
Yes. Each copy of MSVCRT will have it's own heap. But if the same
version is loaded through different paths, it will just use the same
copy. But when they're different versions or flags, you get two
completely separate heaps in the app. Which is exactly the reason why
we added that function to libpq.
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/