Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
От | Jeff Janes |
---|---|
Тема | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Дата | |
Msg-id | CAMkU=1zYO6B_g1a4rGCwqOErKH-ucZmN1fpnUuQZittu5AgO+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
On Mon, Mar 5, 2012 at 8:50 AM, Heikki Linnakangas <heikki.linnakangas@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
В списке pgsql-hackers по дате отправления: