Skip site navigation (1) Skip section navigation (2)

AW: AW: WAL & RC1 status

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: WAL & RC1 status
Date: 2001-03-05 16:47:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > One issue about too many checkpoints in pg_control, is that you then
> > need to keep more logs, and in my pgbench tests the log space was a
> > real issue, even for the one checkpoint case. I think a utility to
> > recreate a busted pg_control would add a lot more stability, than one
> > more checkpoint in pg_control.
> Well, there is a big difference between 1 and 2 checkpoints stored in
> pg_control.  I don't intend to go further than 2.  But I disagree about
> a log-reset utility being more useful than an extra checkpoint.

Yes I agree, I thought there was already one additional checkpoint info in 

>  The
> utility would be for manual recovery after a disaster, and it wouldn't
> offer 100% recovery: you couldn't be sure that the last few transactions
> had been applied atomically, ie, all or none.  (Perhaps pg_log got
> updated to show them committed, but not all of their tuple changes made
> it to disk; how will you know?)  If you can back up to the prior
> checkpoint and then roll forward, you *do* have a shot at guaranteeing
> a consistent database state after loss of the primary checkpoint.

Yes, but a consistent db can only be guaranteed if all txlog logs up to the 
crash are eighter rolled forward or at least the physical log pages are written 
back to disk.

The consequence is imho, that a good utility to reset the logs should keep
all "physical log" pages, and only clear the log from all other records
[optionally starting at the position that hinders rollforward].


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-03-05 18:31:50
Subject: WAL-based allocation of XIDs is insecure
Previous:From: Tom LaneDate: 2001-03-05 16:26:38
Subject: Re: Query Planning time increased 3 times on 7.1 compared to 7.0.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group