Re: patch for parallel pg_dump - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: patch for parallel pg_dump
Date
Msg-id CACw0+11a8xUJ+pFXNP0Ojv3qNmc9fQ2BZAsiWnXEGauf=wW8tQ@mail.gmail.com
Whole thread Raw
In response to Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch for parallel pg_dump
List pgsql-hackers
On Wed, Feb 8, 2012 at 1:21 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> In my patch I dealt with exactly the same problem for the error
>> handler by creating a separate function that has a static variable (a
>> pointer to the ParallelState). The value is set and retrieved through
>> the same function, so yes, it's kinda global but then again it can
>> only be accessed from this function, which is only called from the
>> error handler.
>
> How did you make this thread-safe?

The ParallelState has a ParallelSlot for each worker process which
contains that worker process's thread id. So a worker process just
walks through the slots until it finds its own thread id and then goes
from there.

In particular, it only gets the file descriptors to and from the
parent from this structure, to communicate the error it encountered,
but it doesn't get the PGconn. This is because that error handler is
only called when a worker calls die_horribly(AH, ...) in which case
the connection is already known through AH.

Termination via a signal just sets a variable that is checked in the
I/O routines and there we also have AH to shut down the connection
(actually to call die_horribly()).


> So we at least need to press on far enough to get to that point.

Sure, let me know if I can help you with something.


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Progress on fast path sorting, btree index creation time
Next
From: Greg Smith
Date:
Subject: Re: Vacuum rate limit in KBps