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

Proposed WAL changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Proposed WAL changes
Date: 2001-03-06 04:39:17
Message-ID: 4514.983853557@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I have just sent to the pgsql-patches list a rather large set of
proposed diffs for the WAL code.  These changes:

* Store two past checkpoint locations, not just one, in pg_control.
  On startup, we fall back to the older checkpoint if the newer one
  is unreadable.  Also, a physical copy of the newest checkpoint record
  is kept in pg_control for possible use in disaster recovery (ie,
  complete loss of pg_xlog).  Also add a version number for pg_control
  itself.  Remove archdir from pg_control; it ought to be a GUC
  parameter, not a special case (not that it's implemented yet anyway).

* Suppress successive checkpoint records when nothing has been entered
  in the WAL log since the last one.  This is not so much to avoid I/O
  as to make it actually useful to keep track of the last two
  checkpoints.  If the things are right next to each other then there's
  not a lot of redundancy gained...

* Change CRC scheme to a true 64-bit CRC, not a pair of 32-bit CRCs
  on alternate bytes.

* Fix XLOG record length handling so that it will work at BLCKSZ = 32k.

* Change XID allocation to work more like OID allocation, so that we
  can flush XID alloc info to the log before there is any chance an XID
  will appear in heap files.

* Fix a number of minor bugs, such as off-by-one logic for XLOG file
  wraparound at the 4 gig mark.

* Add documentation and clean up some coding infelicities; move file
  format declarations out to include files where planned contrib
  utilities can get at them.


Before committing this stuff, I intend to prepare a contrib utility that
can be used to reset pg_control and pg_xlog.  This is mainly for
disaster recovery purposes, but as a side benefit it will allow people
to update 7.1beta installations to this new code without doing initdb.
I need to update contrib/pg_controldata, too.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Alfred PerlsteinDate: 2001-03-06 05:43:13
Subject: Re: How to shoot yourself in the foot: kill -9 postmaster
Previous:From: Stephan SzaboDate: 2001-03-06 04:04:11
Subject: Re: Re: pg_dump scripts are no longer ordinary-user friendly

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