> > Yes, writes are only necessary when "too many dirty pages"
> > are in the buffer pool. Those writes can be done by a page flusher
> > on demand or during checkpoint (don't know if we need checkpoint,
> > but you referred to doing checkpoints).
>
> How else to know from where in log to start
> Yes, writes are only necessary when "too many dirty pages"
> are in the buffer pool. Those writes can be done by a page flusher
> on demand or during checkpoint (don't know if we need checkpoint,
> but you referred to doing checkpoints).
How else to know from where in log to start redo and how
> > > 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?
Yes, writes are only necessary when "too many dirty pages"
are in the buffer po
> Do we have the info when a page was last modified (in respect
> to a WAL position, not wallclock time) on each page ? This is
> probably an info we will need.
How else one could know was a change applied to page or not?
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
> >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 )
>
> You may be tying implementation too closely to func
At 10:38 18/10/00 +0200, Zeugswetter Andreas SB wrote:
>
>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 )
You may
> 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 :-)
> > 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 (w
> > >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 ind
> >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 ?
Perf
>> 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 prema
> >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 m
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,
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. |/
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 changin
> >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.
> 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
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 ethymologica
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.
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
> > > 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 curre
At 00:45 16/10/00 -0400, Bruce Momjian wrote:
>What was the matter with the name pg_restore?
The fact that we will have a 'proper' backup/restore with the WAL changes,
and it seems more appropriate that the new utilities should be called
pg_backup & pg_restore. This leaves the 'undump' part of pg
Don't go changing yet. When Vadim has something, we can decide. I
think we may have unique commands for logging control and stuff, so
let's see how it plays out.
> At 00:45 16/10/00 -0400, Bruce Momjian wrote:
> >What was the matter with the name pg_restore?
>
> The fact that we will have a 'p
On Mon, 16 Oct 2000, Bruce Momjian wrote:
> What was the matter with the name pg_restore?
I didn't wanna be the one to ask, but I was kinda confused on that point
too ...
> > Since we may have a workable backup/restore based on WAL available in 7.1,
> > I am now wondering at the wisdom of creat
What was the matter with the name pg_restore?
>
> Since we may have a workable backup/restore based on WAL available in 7.1,
> I am now wondering at the wisdom of creating 'pg_restore', which reads the
> new pg_dump archive files. It is probably better to have pg_backup &
> pg_restore as the bac
Philip Warner <[EMAIL PROTECTED]> writes:
> As a result do people have any objection to changing pg_restore to
> pg_undump? Or pg_load?
Out of those two names, I'd vote for pg_load ...
regards, tom lane
Since we may have a workable backup/restore based on WAL available in 7.1,
I am now wondering at the wisdom of creating 'pg_restore', which reads the
new pg_dump archive files. It is probably better to have pg_backup &
pg_restore as the backup/restore utilities.
As a result do people have any ob
27 matches
Mail list logo
