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

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>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: WAL & RC1 status
Date: 2001-03-05 09:46:50
Message-ID: 11C1E6749A55D411A9670001FA687963368220@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> Since there is not a separate WAL version stamp, introducing one now
> would certainly force an initdb.  I don't mind adding one if you think
> it's useful; another 4 bytes in pg_control won't hurt anything.  But
> it's not going to save anyone's bacon on this cycle.

Yes, if initdb, that would probably be a good idea.
Imho the initdb now is not a real issue, since all beta testers
know that for serious issues there might be an initdb after beta started.

> At least one of my concerns (single point of failure) would require a
> change to the layout of pg_control, which would force initdb anyway.

Was that the "only one checkpoint back in time in pg_control" issue ?
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.

We should probably have additional criteria to time, that can trigger a 
checkpoint, like N logs filled since last checkpoint. I do not think 
reducing the checkpoint interval is a solution for once in a while heavy activity.

Andreas

Responses

pgsql-hackers by date

Next:From: Justin CliftDate: 2001-03-05 10:39:09
Subject: Re: Getting unique ID through SQL
Previous:From: Hiroshi InoueDate: 2001-03-05 08:50:49
Subject: Re: How to handle waitingForLock in LockWaitCancel()

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