Re: 8.5 release timetable, again

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.5 release timetable, again
Date: 2009-08-27 15:38:13
Message-ID: 407d949e0908270838kde9bb7eu7a3d9849095a2152@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 27, 2009 at 3:11 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Precisely...
>
> What I'd like to see is some sort of test mechanism for WAL recovery.
> What I've done sometimes in the past (and recently had to fix the tests
> to re-enable) is to kill -9 a backend immediately after running the
> regression tests, let the system replay the WAL for the tests, and then
> take a pg_dump and compare that to the dump gotten after a conventional
> run.  However this is quite haphazard since (a) the regression tests
> aren't especially designed to exercise all of the WAL logic, and (b)
> pg_dump might not show the effects of some problems, particularly not
> corruption in non-system indexes.  It would be worth the trouble to
> create a more specific test methodology.

What I've been thinking of doing is having the regression suite take a
backup after initdb and set archive mode on. when the regression suite
finishes start the backup up and replay all the WAL.

I'm not sure how to compare the databases since I don't think pg_dump
actually works here -- a lot of the data is dropped by the end of the
test. But at least that would test that replaying WAL didn't cause any
crashes.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-27 15:43:36 Re: fillfactor hides autovacuum parameters in 8.4.0
Previous Message Magnus Hagander 2009-08-27 15:35:19 Re: BUG #4996: postgres.exe memory consumption keeps going up