Re: corrupt pages detected by enabling checksums
От | Jeff Davis |
---|---|
Тема | Re: corrupt pages detected by enabling checksums |
Дата | |
Msg-id | 1365105576.14231.58.camel@jdavis обсуждение исходный текст |
Ответ на | Re: corrupt pages detected by enabling checksums (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: corrupt pages detected by enabling checksums
|
Список | pgsql-hackers |
Andres, Thank you for diagnosing this problem! On Thu, 2013-04-04 at 16:53 +0200, Andres Freund wrote: > I think the route you quickly sketched is more realistic. That would > remove all knowledge obout XLOG_HINT from generic code hich is a very > good thing, I spent like 15minutes yesterday wondering whether the early > return in there might be the cause of the bug... I like this approach. It may have some performance impact though, because there are a couple extra spinlocks taken, and an extra memcpy. The code looks good to me except that we should be consistent about the page hole -- XLogCheckBuffer is calculating it, but then we copy the entire page. I don't think anything can change the size of the page hole while we have a shared lock on the buffer, so it seems OK to skip the page hole during the copy. Another possible approach is to drop the lock on the buffer and re-acquire it in exclusive mode after we find out we'll need to do XLogInsert. It means that MarkBufferDirtyHint may end up blocking for longer, but would avoid the memcpy. I haven't really thought through the details. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: