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: | Raw Message | Whole Thread | 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) |