From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Date: | 2012-03-07 15:44:19 |
Message-ID: | CAMkU=1zYO6B_g1a4rGCwqOErKH-ucZmN1fpnUuQZittu5AgO+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 5, 2012 at 8:50 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-03-07 15:55:12 | Re: review: CHECK FUNCTION statement |
Previous Message | Robert Haas | 2012-03-07 15:39:40 | Re: pg_stat_statements and planning time |