From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'J(dot) R(dot) Nield'" <jrnield(at)usol(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Tucker <richt(at)multera(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PITR, checkpoint, and local relations |
Date: | 2002-08-02 22:00:46 |
Message-ID: | 3705826352029646A3E91C53F7189E325185D7@sectorbase2.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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
Correction - *after*-image.
> time for speed without fear of data-loss. Didn't we have
> this discussion before?
Sorry, I missed this.
So, it's already discussed what to do about partial
block updates? When system crashed just after LSN,
but not actual tuple etc, was stored in on-disk block
and on restart you compare log record' LSN with
data block' LSN, they are equal and so you *assume*
that actual data are in place too, what is not the case?
I always thought that the whole point of PITR is to be
able to restore DB fast (faster than pg_restore) *AND*
up to the last committed transaction (assuming that
log is Ok).
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2002-08-02 22:01:11 | Re: PITR, checkpoint, and local relations |
Previous Message | Mikheev, Vadim | 2002-08-02 21:49:57 | Re: PITR, checkpoint, and local relations |