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

2016-09-27 Thread Tom Lane
Kevin Grittner writes: > This patch applies with a few minor offsets, compiles without > warning, and passes all regression tests including `make > check-world` with TAP tests enabled. This and the related patch > dealing with the parallel API definitely make things cleaner and > easier to follow

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

2016-09-27 Thread Kevin Grittner
This patch applies with a few minor offsets, compiles without warning, and passes all regression tests including `make check-world` with TAP tests enabled. This and the related patch dealing with the parallel API definitely make things cleaner and easier to follow. I find it disappointing that AC

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

2016-06-02 Thread Tom Lane
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 o

[HACKERS] Redesigning parallel dump/restore's wait-for-workers logic

2016-05-29 Thread Tom Lane
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. That code is messy and hard to use --- if the existing logic in restore_toc_entries_parallel d