Re: parallel restore fixes - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: parallel restore fixes
Date
Msg-id 49B5B632.4040302@dunslane.net
Whole thread Raw
In response to Re: parallel restore fixes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: parallel restore fixes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Tom Lane wrote:
>> It makes me a bit
>> nervous because there are some other programs that are linking
>> dumputils.c (psql and some in src/bin/scripts/) and even calling fmtId.
>>     
>
> Actually, why bother with init_dump_utils at all?  fmtId could be made
> to initialize the ID variable for itself on first call, with only one
> extra if-test, which is hardly gonna matter.
>
>     

Well, the Windows reference I have suggests TlsAlloc() needs to be 
called early in the initialisation process ... I guess I could force it 
with a dummy call to fmtId() in restore_toc_entries_parallel() before it 
starts spawning children, so we'd be sure there wasn't a race condition, 
and nothing else is going to have threads so it won't matter. We'd need 
a long comment to that effect, though ;-)

> I'd lose the added retval
> variable too; that's not contributing anything.

It is, in fact. Until I put that in I was getting constant crashes. I 
suspect it's something to do with stuff Windows does under the hood on 
function return.

cheers

andrew





pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)
Next
From: KaiGai Kohei
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)