Re: small parallel restore optimization

Magnus Hagander wrote:
> Andrew Dunstan wrote:
>   
>> Alvaro Herrera wrote:
>>     
>>> Andrew Dunstan wrote:
>>>
>>>  
>>>       
>>>> I have found the source of the problem I saw. dumputils.c:fmtId()
>>>> uses a  static PQExpBuffer which it initialises the first time it's
>>>> called. This  gets clobbered by simultaneous calls by Windows threads.
>>>>
>>>> I could just make it auto and set it up on each call, but that could 
>>>> result in a non-trivial memory leak ... it's probably called a great 
>>>> many times. Or I could provide a parallel version where we pass in a 
>>>> PQExpBuffer that we create, one per thread, and is used by anything 
>>>> called by the parallel code. That seems like a bit of a potential 
>>>> footgun, though.
>>>>     
>>>>         
>>> Could you use a different static PQExpBuffer on each thread?
>>> pthread_getspecific sort of thing, only to be used on Windows.
>>>   
>>>       
>> For MSVC we could declare it with "_declspec(thread)" and it would be
>> allocated in thread-local storage, but it looks like this isn't
>> supported on Mingw.
>>     
>
> Yeah, _declspec(thread) would be the easy way to do it. But you can also
> use the TlsAlloc(), TlsSetValue() and friends functions directly. We do
> this to use TLS in ecpg.
>
> It requires some coding around, but for ecpg we did a macro that makes
> it behave like the posix functions (see
> src/interfaces/ecpg/include/ecpg-pthread-win32.h)
>
>
>   


Yeah, we'll just have to call TlsAlloc to set the thread handle 
somewhere near program start, but that shouldn't be too intrusive.

cheers

andrew