On 12 October 2012 20:07, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 11, 2012 at 3:37 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 11 October 2012 20:30, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Thu, Oct 11, 2012 at 2:42 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>>> I have a quietish few days starting on Saturday, will be looking at this
>>>> then. Is it only the Windows aspect that needs reviewing? Are we more or
>>>> less happy with the rest?
>>>
>>> I think the Windows issues were the biggest thing, but I suspect there
>>> may be a few other warts as well. It's a lot of code, and it's
>>> modifying pg_dump, which is an absolute guarantee that it's built on a
>>> foundation made out of pure horse manure.
>>
>> That may be so, but enough people dependent upon it that now I'm
>> wondering whether we should be looking to create a new utility
>> altogether, or at least have pg_dump_parallel and pg_dump to avoid any
>> screw ups with people's backups/restores.
>
> Well, I think pg_dump may well need a full rewrite to be anything like
> sane. But I'm not too keen about forking it as part of adding
> parallel dump. I think we can sanely hack this patch into what's
> there now. It's liable to be a bit hard to verify, but in the long
> run having two copies of the code is going to be a huge maintenance
> headache, so we should avoid that.
I agree that maintaining 2 copies of the code would be a huge
maintenance headache in the long run. I wasn't suggesting we do it for
more than 1 release, after which we just have 2 names for same
program.
I think the phrase "a bit hard to verify" probably isn't good in
conjunction with backup utilities, where stability is preferred. I'm
not wedded to my suggestion of how we handle the risk of it going
wrong, but if we see a risk then we should do something about it.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
