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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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