Thread

1. Re: PITR, checkpoint, and local relations

   Vadim Mikheev <vmikheev@sectorbase.com> — 2002-08-02T20:59:47Z

   > > (In particular, I *strongly* object to using the buffer 
   > manager at all
   > > for reading files for backup.  That's pretty much 
   > guaranteed to blow out
   > > buffer cache.  Use plain OS-level file reads.  An OS 
   > directory search
   > > will do fine for finding what you need to read, too.)
   > 
   > How do you get atomic block copies otherwise?
   
   You don't need it.
   As long as whole block is saved in log on first after
   checkpoint (you made before backup) change to block.
   
   Vadim
   
   

2. Re: PITR, checkpoint, and local relations

   J.R. Nield <jrnield@usol.com> — 2002-08-02T21:12:20Z

   On Fri, 2002-08-02 at 16:59, Mikheev, Vadim wrote:
   
   > You don't need it.
   > As long as whole block is saved in log on first after
   > checkpoint (you made before backup) change to block.
   
   I thought half the point of PITR was to be able to turn off pre-image
   logging so you can trade potential recovery time for speed without fear
   of data-loss. Didn't we have this discussion before?
   
   How is this any worse than a table scan?
    
   -- 
   J. R. Nield
   jrnield@usol.com
   
   
   
   
   

3. Re: PITR, checkpoint, and local relations

   Richard Tucker <richt@multera.com> — 2002-08-02T21:40:26Z

   
   > -----Original Message-----
   > From: pgsql-hackers-owner@postgresql.org
   > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of J. R. Nield
   > Sent: Friday, August 02, 2002 5:12 PM
   > To: Mikheev, Vadim
   > Cc: Tom Lane; Richard Tucker; Bruce Momjian; PostgreSQL Hacker
   > Subject: Re: [HACKERS] PITR, checkpoint, and local relations
   >
   >
   > On Fri, 2002-08-02 at 16:59, Mikheev, Vadim wrote:
   >
   > > You don't need it.
   > > As long as whole block is saved in log on first after
   > > checkpoint (you made before backup) change to block.
   >
   > I thought half the point of PITR was to be able to turn off pre-image
   > logging so you can trade potential recovery time for speed without fear
   > of data-loss. Didn't we have this discussion before?
   Suppose you can turn off/on PostgreSQL's atomic write on the fly.  Which
   means turning on or off whether XLoginsert writes a copy of the block into
   the log file upon first modification after a checkpoint.
   So ALTER SYSTEM BEGIN BACKUP would turn on atomic write and then checkpoint
   the database.
   So while the OS copy of the data files is going on the atomic write would be
   enabled. So any read of a partial write would be fixed up by the usual crash
   recovery mechanism.
   >
   > How is this any worse than a table scan?
   >
   > --
   > J. R. Nield
   > jrnield@usol.com
   >
   >
   >
   >
   > ---------------------------(end of broadcast)---------------------------
   > TIP 4: Don't 'kill -9' the postmaster
   >