Re: parallel restore fixes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: parallel restore fixes
Date
Msg-id 19822.1236650947@sss.pgh.pa.us
Whole thread Raw
In response to Re: parallel restore fixes  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: parallel restore fixes  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> How early is early?  The proposed call sites for init_dump_utils seem
>> already long past the point where any libc-level infrastructure would
>> think it is "initialization" time.

> Well, I think at least it needs to be done where other threads  won't be 
> calling it at the same time.

Oh, I see, ye olde race condition.  Still, it seems like a bad idea
to expect that we will catch every program that might call fmtId;
as Alvaro notes, that's all over our client-side code.

How about this: by default, fmtId uses the same logic as now (one static
PQExpBuffer).  If told to by a call of init_parallel_dump_utils(), which
need only be called by pg_restore during its startup, then it switches to
using per-thread storage.  init_parallel_dump_utils can be the place
that calls TlsAlloc.  This is almost the same as what you suggested a
couple messages back, but perhaps a bit clearer as to what's going on;
and it definitely cuts the number of places we need to touch.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sampling Profler for Postgres
Next
From: Jaime Casanova
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1704)