Re: WAL & RC1 status
От | ncm@zembu.com (Nathan Myers) |
---|---|
Тема | Re: WAL & RC1 status |
Дата | |
Msg-id | 20010302125412.P624@store.zembu.com обсуждение исходный текст |
Ответ на | Re: WAL & RC1 status (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: WAL & RC1 status
Re: WAL & RC1 status |
Список | pgsql-hackers |
On Fri, Mar 02, 2001 at 10:54:04AM -0500, Bruce Momjian wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Is there a version number in the WAL file? > > > > catversion.h will do fine, no? > > > > > Can we put conditional code in there to create > > > new log file records with an updated format? > > > > The WAL stuff is *far* too complex already. I've spent a week studying > > it and I only partially understand it. I will not consent to trying to > > support multiple log file formats concurrently. > > Well, I was thinking a few things. Right now, if we update the > catversion.h, we will require a dump/reload. If we can update just the > WAL version stamp, that will allow us to fix WAL format problems without > requiring people to dump/reload. I can imagine this would be valuable > if we find we need to make changes in 7.1.1, where we can not require > dump/reload. It Seems to Me that after an orderly shutdown, the WAL files should be, effectively, slag -- they should contain no deltas from the current table contents. In practice that means the only part of the format that *should* matter is whatever it takes to discover that they really are slag. That *should* mean that, at worst, a change to the WAL file format should only require doing an orderly shutdown, and then (perhaps) running a simple program to generate a new-format empty WAL. It ought not to require an initdb. Of course the details of the current implementation may interfere with that ideal, but it seems a worthy goal for the next beta, if it's not possible already. Given the opportunity to change the current WAL format, it ought to be possible to avoid even needing to run a program to generate an empty WAL. Nathan Myers ncm@zembu.com
В списке pgsql-hackers по дате отправления: