Re: parallel restore fixes
От | Andrew Dunstan |
---|---|
Тема | Re: parallel restore fixes |
Дата | |
Msg-id | 49B5B632.4040302@dunslane.net обсуждение исходный текст |
Ответ на | Re: parallel restore fixes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: parallel restore fixes
|
Список | 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 по дате отправления: