Re: patch for parallel pg_dump

Поиск
Список
Период
Сортировка
От Joachim Wieland
Тема Re: patch for parallel pg_dump
Дата
Msg-id CACw0+11a8xUJ+pFXNP0Ojv3qNmc9fQ2BZAsiWnXEGauf=wW8tQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: patch for parallel pg_dump  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Progress on fast path sorting, btree index creation time
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Vacuum rate limit in KBps