Re: Proposed WAL changes

> I have just sent to the pgsql-patches list a rather large set of

Please send it to me directly - pgsql-patches' archieve is dated by Feb -:(

> 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

And what to do if older one is unreadable too?
(Isn't it like using 2 x CRC32 instead of CRC64 ? -:))
And what to do if pg_control was lost? (We already discussed that we
should read all logs from newest to oldest ones to find checkpoint).
And why to keep old log files with older checkpoint?

>   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

Mmmm, how recovery is possible if log was lost? All what could be done
with DB in the event of corrupted/lost log is dumping data from tables
*asis*, without any guarantee about consistency. How checkpoint' content
could be useful?

I feel that the fact that

WAL can't help in the event of disk errors

is often overlooked.

>   itself.  Remove archdir from pg_control; it ought to be a GUC
>   parameter, not a special case (not that it's implemented yet anyway).

I would discuss WAL based BAR management before deciding how to
store/assign archdir. On the other hand it's easy to add archdir
to pg_control later -:)

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

Great if you've found reliable CRC64 impl!

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

Case I've overlooked -:(
(Though, I always considered BLCKSZ > 8K as temp hack -:))

> * 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.

I didn't read you postings about this yet.

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

Thanks for that!
> 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

Once again, I would call this "disaster *dump* purposes" -:)
After such operation DB shouldn't be used for anything but dump!

> to update 7.1beta installations to this new code without doing initdb.
> I need to update contrib/pg_controldata, too.

Vadim