Re: Proposed WAL changes - Mailing list pgsql-hackers
From | Vadim Mikheev |
---|---|
Subject | Re: Proposed WAL changes |
Date | |
Msg-id | 04c701c0a6e6$1850a0c0$4879583f@sectorbase.com Whole thread Raw |
In response to | Proposed WAL changes (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Proposed WAL changes
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposed WAL changes (The Hermit Hacker <scrappy@hub.org>) |
List | pgsql-hackers |
> 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
pgsql-hackers by date: