Re: Redesigning parallel dump/restore's wait-for-workers logic

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Redesigning parallel dump/restore's wait-for-workers logic
Date: 2016-06-02 18:57:35
Message-ID: 6814.1464893855@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> One of the things I do not like about the current coding of parallel
> pg_dump/pg_restore is its baroque logic for handling worker completion
> reports, specifically the ListenToWorkers/ReapWorkerStatus APIs.

Here's a version of this patch rebased over e652273e073566b6.

Since this is only refactoring, and doesn't (I think) fix any bugs,
I'm setting it aside till the next commitfest.

regards, tom lane

Attachment Content-Type Size
parallel-dump-waiting-2.patch text/x-diff 34.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-02 19:48:42 Re: Misdesigned command/status APIs for parallel dump/restore
Previous Message Tom Lane 2016-06-02 18:29:34 Re: pg9.6 segfault using simple query (related to use fk for join estimates)