Re: Misdesigned command/status APIs for parallel dump/restore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Misdesigned command/status APIs for parallel dump/restore
Date: 2016-06-01 18:29:30
Message-ID: 32559.1464805770@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I am pretty strongly tempted to get rid of MasterStartParallelItem
> altogether and just hard-code what it does in DispatchJobForTocEntry.
> ...
> A different line of thought would be to fix the worker-command-parsing
> situation by allowing the parsing to happen in format-specific code,
> but avoid duplicative coding by letting archive formats share a common
> implementation function if they had no need for any custom data.

In the attached patch for this, I took a middle ground of separating out
the command and status string building and parsing functions. There isn't
presently any provision for letting archive format modules override these,
but that could easily be added if we ever need it. Meanwhile, this saves
about 100 lines of rather messy code.

Like the other couple of patches I've posted recently for parallel dump,
this is against current HEAD. There will be minor merge conflicts when
these patches are combined; but they should be reviewable independently,
so I'll worry about the merge issues later.

regards, tom lane

Attachment Content-Type Size
cleaner-dump-command-status-APIs.patch text/x-diff 23.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-06-01 18:40:19 Re: JSON[B] arrays are second-class citizens
Previous Message Paul Ramsey 2016-06-01 18:00:19 Re: Floating point comparison inconsistencies of the geometric types