Re: corrupt pages detected by enabling checksums
От | Andres Freund |
---|---|
Тема | Re: corrupt pages detected by enabling checksums |
Дата | |
Msg-id | 20130405130911.GM2415@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: corrupt pages detected by enabling checksums (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: corrupt pages detected by enabling checksums
Re: corrupt pages detected by enabling checksums Re: corrupt pages detected by enabling checksums |
Список | pgsql-hackers |
On 2013-04-04 17:39:16 -0700, Jeff Davis wrote: > On Thu, 2013-04-04 at 22:39 +0200, Andres Freund wrote: > > I don't think its really slower. Earlier the code took WalInsertLock > > everytime, even if we ended up not logging anything. Thats far more > > epensive than a single spinlock. And the copy should also only be taken > > in the case we need to log. So I think we end up ahead of the current > > state. > > Good point. > > > > 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. > > > > I don't think it can change either, but I doubt that there's a > > performance advantage by not copying the hole. I'd guess the simpler > > code ends up faster. > > I was thinking more about the WAL size, but I don't have a strong > opinion. I was just a bit dense. No idea what I missed there. How does the attached version look? I verified that it survives recovery, but not more. Jeff, any chance you can run this for a round with your suite? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: