Skip site navigation (1) Skip section navigation (2)

Re: patch for parallel pg_dump

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch for parallel pg_dump
Date: 2012-02-09 00:56:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 8, 2012 at 1:21 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

In response to


pgsql-hackers by date

Next:From: Amit KapilaDate: 2012-02-09 03:11:25
Subject: Re: double writes using "double-write buffer" approach [WIP]
Previous:From: Peter GeogheganDate: 2012-02-09 00:54:36
Subject: Re: Progress on fast path sorting, btree index creation time

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group