Re: WIP patch for parallel pg_dump - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: WIP patch for parallel pg_dump
Date
Msg-id AANLkTimwgM8=Gy9r-ydLXtPJvNq=zj7OEsvpLRXJReKP@mail.gmail.com
Whole thread Raw
In response to Re: WIP patch for parallel pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP patch for parallel pg_dump  (Andrew Dunstan <andrew@dunslane.net>)
Re: WIP patch for parallel pg_dump  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
On Thu, Dec 2, 2010 at 9:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In particular, this issue *has* been discussed before, and there was a
> consensus that preserving dump consistency was a requirement.  I don't
> think that Joachim gets to bypass that decision just by submitting a
> patch that ignores it.

I am not trying to bypass anything here :)  Regarding the locking
issue I probably haven't done sufficient research, at least I managed
to miss the emails that mentioned it. Anyway, that seems to be solved
now fortunately, I'm going to implement your idea over the weekend.

Regarding snapshot cloning and dump consistency, I brought this up
already several months ago and asked if the feature is considered
useful even without snapshot cloning. And actually it was you who
motivated me to work on it even without having snapshot consistency...

http://archives.postgresql.org/pgsql-hackers/2010-03/msg01181.php

In my patch pg_dump emits a warning when called with -j, if you feel
better with an extra option
--i-know-that-i-have-no-synchronized-snapshots, fine with me :-)

In the end we provide a tool with limitations, it might not serve all
use cases but there are use cases that would benefit a lot. I
personally think this is better than to provide no tool at all...


Joachim


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: Author names in source files
Next
From: Heikki Linnakangas
Date:
Subject: Re: should we set hint bits without dirtying the page?