Thread: AW: Backup, restore & pg_dump
> > > As a result do people have any objection to changing pg_restore to > > > pg_undump? Or pg_load? Also possible would be a name like Oracle pg_exp and pg_imp for export and import. (or pg_export and pg_import) Load and unload is often more tied to data only (no dml). I agree that the current name pg_restore for its current functionality is not good and misleading in the light of WAL backup. Andreas
I like the pg_{import,export} names myself ... *nod*
On Mon, 16 Oct 2000, Zeugswetter Andreas SB wrote:
>
> > > > As a result do people have any objection to changing pg_restore to
> > > > pg_undump? Or pg_load?
>
> Also possible would be a name like Oracle
> pg_exp and pg_imp for export and import.
> (or pg_export and pg_import)
>
> Load and unload is often more tied to data only (no dml).
>
> I agree that the current name pg_restore for its current functionality
> is not good and misleading in the light of WAL backup.
>
> Andreas
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
At 10:08 16/10/00 -0300, The Hermit Hacker wrote:
>
>I like the pg_{import,export} names myself ... *nod*
>
Sounds fine also; but we have compatibility issues in that we still need
pg_dump. Maybe just a symbolic link to pg_export.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
Philip Warner writes:
> >I like the pg_{import,export} names myself ... *nod*
>
> Sounds fine also; but we have compatibility issues in that we still need
> pg_dump. Maybe just a symbolic link to pg_export.
I'm not so fond of changing a long-established program name for the sake
of ethymological correctness or consistency with other products (yeah,
right). I got plenty of suggestions if you want to start that. I say
stick to pg_dump[all], and name the inverse pg_undump, pg_load, or
pmud_gp.
Btw., it will still be possible to restore, er, reload, with psql, right?
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> Philip Warner writes:
>
> > >I like the pg_{import,export} names myself ... *nod*
> >
> > Sounds fine also; but we have compatibility issues in that we still need
> > pg_dump. Maybe just a symbolic link to pg_export.
>
> I'm not so fond of changing a long-established program name for the sake
> of ethymological correctness or consistency with other products (yeah,
Agreed.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> >I like the pg_{import,export} names myself ... *nod*
> >
>
> Sounds fine also; but we have compatibility issues in that we
> still need pg_dump. Maybe just a symbolic link to pg_export.
Yes, we still need in pg_dump, because of pg_dump is thing
quite different from WAL based backup/restore. pg_dump
is utility to export data in system independant format
using standard SQL commands (with COPY extension) and WAL
based backup system is to export *physical* data files
(and logs). So, pg_dump should be preserved asis.
Vadim
On Tue, 17 Oct 2000, Peter Eisentraut wrote:
> Philip Warner writes:
>
> > >I like the pg_{import,export} names myself ... *nod*
> >
> > Sounds fine also; but we have compatibility issues in that we still need
> > pg_dump. Maybe just a symbolic link to pg_export.
>
> I'm not so fond of changing a long-established program name for the sake
> of ethymological correctness or consistency with other products (yeah,
> right). I got plenty of suggestions if you want to start that. I say
> stick to pg_dump[all], and name the inverse pg_undump, pg_load, or
> pmud_gp.
pmud_gp? *raised eyebrow*
At 00:12 17/10/00 +0200, Peter Eisentraut wrote: > >Btw., it will still be possible to restore, er, reload, with psql, right? > Correct. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
At 15:07 16/10/00 -0700, Mikheev, Vadim wrote: > >So, pg_dump should be preserved asis. > Just to clarify; I have no intention of doing anything nasty to pg_dump. All I plan to do is rename the pg_restore to one of pg_load/pg_import/pg_undump/pmud_gp, to make way for a WAL based restore utility, although as Bruce suggests, this may be premature. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
>> Just to clarify; I have no intention of doing anything nasty to pg_dump. Oh, ok, it wasn't clear, sorry -:) >>All I plan to do is rename the pg_restore to one of >>pg_load/pg_import/pg_undump/pmud_gp, to make way for a WAL based >>restore utility, although as Bruce suggests, this may be premature. > >It is not premature. We will need a WAL based restore for 7.1 >or we imho don't need to enable WAL for 7.1 at all. I missed your point here - why ?! New backup/restore is not only result of WAL. What about recovery & performance? Hm, WAL is required for distributed transactions and we are not going to have them in 7.1 - does it also mean that we don't need to enable WAL in 7.1? There is WAL - general mechanism for transaction recovery & performance, alternative (with regard to non-overwriting storage manager) approach to transaction systems. And there are WAL based features. Sooner we'll get base sooner we'll have features. Vadim
> > >It is not premature. We will need a WAL based restore for 7.1 > > >or we imho don't need to enable WAL for 7.1 at all. > > > > I missed your point here - why ?! > > New backup/restore is not only result of WAL. > > What about recovery & performance? > > Ok, recovery is only improved for indexes, no ? > Performance must imho be worse in your first round > (at least compared to -F mode). ^^^^^^^^ only > There is room for improvement that was not there > before WAL (like avoiding write calls, non-overwrite ...) > but those are not implemented yet. And what? If there will be no WAL with base functionality now then there will be no additional WAL benefits (eg savepoints) later. WAL based backup/reatore is one of additional WAL benefit. *Hopefully* we'll be able to implement it now. BTW, avoiding writes is base WAL feature, ie - it'll be implemented in 7.1. > Please correct me if I am wrong here, but imho we accept that > slowdown, because we gain so much. > > > Hm, WAL is required for distributed transactions > > and we are not going to have them in 7.1 - does it > > also mean that we don't need to enable WAL in 7.1? > > No, but rollforward is currently the main feature, no ? I'm going to rollback changes on abort in 7.1. Seems I've mentioned both redo and UNDO (without compensation records) AM methods many times. > Does it make sense to ship WAL without using it's currently > main feature ? Sorry, but it's not always possible to have all at once. But again, hopefully we'll have backup/restore. Thanks to Philip. (BTW, replication server prototype announced by Pgsql, Inc could be used for incremental backup) Vadim
> > BTW, avoiding writes is base WAL feature, ie - it'll be > > implemented in 7.1. > > Wow, great, I thought first step was only to avoid sync :-) ? If syncs are not required then why to do write call? > > > No, but rollforward is currently the main feature, no ? > > > > I'm going to rollback changes on abort in 7.1. Seems I've > > mentioned both redo and UNDO (without compensation records) > > AM methods many times. > > I don't think that I misunderstood anything here. If the commit > record is in the tx log this tx will have to be rolled forward, and > not aborted. Of course open tx's on abort will be rolled back. > But this roll forward for committed tx could be a starting point, no? Currently records inserted by aborted transactions remain in db untill vacuum. I try to rollback changes - ie *delete* inserted tuples on abort (though could do not do this), - isn't there some difference now? > > > Does it make sense to ship WAL without using it's currently > > > main feature ? > > > > Sorry, but it's not always possible to have all at once. > > Sorry, my main point was not to argument against WAL in 7.1, > but to state, that backup/restore would be very important. Yes but I'm not able to do this work. And note that with WAL in 7.1 we could add backup/restore in any version > 7.1 (eg 7.1.1). > > (BTW, replication server prototype announced by Pgsql, Inc > > could be used for incremental backup) > > Yes, that could be a good starting point for rollforward if it is > based on WAL. It's not. > We should not call this tx log business "Incremental backup" > an incremental backup scans all pages, and backs > them up if they changed in respect to the last higher level backup. > (full backup, level 1 backup, level 2 backup ....) > Oracle only uses this chargon, since they don't have such a > backup, and want to fool their customer's managers. > All other DB companies make correct use of the wording > "incremental backup" in the above sense. Scanning *all* pages?! Not the best approach imho. Or did you meant scanning log to get last *committed" changes to all pages - ie some kind of log compression? Vadim