Re: pg_dump schema breakup

From: Naz Gassiep <naz(at)mira(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andreas Joseph Krogh <andreak(at)officenet(dot)no>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump schema breakup
Date: 2006-08-19 07:44:46
Message-ID: 44E6C16E.8000200@mira.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:
<blockquote cite="mid24553(dot)1155932458(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap="">Andrew Dunstan <a class="moz-txt-link-rfc2396E"
href="mailto:andrew(at)dunslane(dot)net">&lt;andrew(at)dunslane(dot)net&gt;</a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Well, the other issue is how many canned breakup schemes we are going to
support. If this particular one is of sufficiently general usefulness
then I have no objection. But when you can produce it trivially from the
output of "pg_dump -s", the need to hardcode it hardly seems pressing.
</pre>
</blockquote>
<pre wrap=""><!---->
FWIW, I am in favor of providing a way to break up the dump output like
this, I was merely objecting to the vocabulary ;-). We have certainly
seen tons of people burnt by the performance problems inherent in
separate-data-and-schema restores, and splitting the dump into three
parts instead of two seems like it would fix that.

But I also like Alvaro's comment that this should be on the restore side
not so much the dump side. If you do two or three successive pg_dump
runs to make your dump then you run a nontrivial risk of not getting
consistent dumps. My advice to people would be to do *one* full
"pg_dump -Fc" and then extract three scripts out of that.

The question then is whether it's worth providing the extraction
functionality in a more canned, user-friendly form than "here, hack up
the -L output with this perl script". I'd vote yes.

regards, tom lane</pre>
</blockquote>
I greatly appreciate the comments here and am glad that my initial idea
has support. This thread highlights to me the difference between the
"hey there's a good idea there despite the fact that's he's obviously
not a veteran software developer" culture that the PostgreSQL community
has instead of the "he is obviously not a veteran software developer so
what on Earth could he have to offer us" responses I've had from
various other open source projects.<br>
<br>
On a less obsequious note, I agree that pg_dump should be used to dump
everything in a single run to avoid consistency issues, and the
selection of data to be restored should be done with pg_restore. As
this is a feature that I would benefit greatly from, how do I go about
ensuring that this idea finds its way to the appropriate developer and
doesn't get forgotten in the mountain of ideas in the "that'd be nice
to have some day" category?<br>
<br>
- Naz<br>
</body>
</html>

Attachment Content-Type Size
unknown_filename text/html 2.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dhanaraj M 2006-08-19 08:22:24 Re: Patch for - Change FETCH/MOVE to use int8
Previous Message Volkan YAZICI 2006-08-19 06:15:59 Input Function (domain_in) Call