Re: [HACKERS] RE: [GENERAL] Transaction logging - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: [HACKERS] RE: [GENERAL] Transaction logging
Date
Msg-id 378EE0D6.21E5B2F9@krs.ru
Whole thread Raw
In response to Re: [HACKERS] RE: [GENERAL] Transaction logging  (Vadim Mikheev <vadim@krs.ru>)
List pgsql-hackers
Vadim Mikheev wrote:
> 
> > The "restore of a server" is a main problem here, but I suggest the
> > following
> > additional backup tool, that could be used for a "restore of a server"
> > which could then be used for a rollforward and would also be a lot faster
> > than a pg_dump:
> >
> > 1. place a vacuum lock on db (we don't want vacuum during backup)
> > 2. backup pg_log using direct file access (something like dd bs=32k)
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 3. backup the rest in any order (same as pg_log)
> > 4. release vacuum lock
> 
> It looks like log archiving, not backup.
> I believe that _full_ backup will do near the same
> things as pg_dump now, but _incremental_ backup will
> fetch info about what changed after last _full_ backup
> from log.

Sorry, I was wrong. pg_dump is what's known as Export utility
in Oracle and backup is quite different thing. But I have
corrections for full backup described above:

1. no vacuum lock is needed: all vacuum ops will be logged  in normal way to rollback changes in failures;
2. all datafiles have to be backed up _before_ log backup  due to WAL logic: changes must be written to log before
they'llbe written to on-disk data pages.
 

Vadim


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] final #include cleanup
Next
From: "Ansley, Michael"
Date:
Subject: RE: [HACKERS] MAX Query length