Re: parallel restore fixes

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

In response to

Responses

Browse pgsql-hackers by date

  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)