On Mon, Mar 5, 2012 at 8:50 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > > That particular issue would be very hard to hit in practice, so I don't know > if this could explain the recovery failures that Jeff saw. I got the test > script running (thanks for that Jeff!), but unfortunately have not seen any > failures yet (aside from the issue with crossing xlogid boundary), with > either this or the older version of the patch. > > Attached is a new version of the patch.
I've run patch v10 for 14109 cycles of crash and recovery, and there were 8 assertion failures at "xlog.c", Line: 2106 during the end-of-recovery checkpoint. How many cycles have you run? Assuming the crashes follow a simple binomial distribution with the frequency I see, you would have to run for ~1230 cycles for a 50% chance of experiencing at least one, or for ~8120 cycles for a 99% chance of experiencing at least one. I think Fujii's method if provoking this problem is more efficient than mine, although I haven't tried it myself. Dual Core AMD Opteron(tm) Processor 275 2.6.32.36-0.5-default #1 SMP 2011-04-14 10:12:31 +0200 x86_64 x86_64 x86_64 GNU/Linux Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
