| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: parallel restore fixes | 
| Date: | 2009-03-10 00:37:06 | 
| Message-ID: | 49B5B632.4040302@dunslane.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | KaiGai Kohei | 2009-03-10 00:41:55 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1704) | 
| Previous Message | Bruce Momjian | 2009-03-10 00:31:11 | Re: Updates of SE-PostgreSQL 8.4devel patches (r1704) |