Re: Patch for fail-back without fresh backup
От | Andres Freund |
---|---|
Тема | Re: Patch for fail-back without fresh backup |
Дата | |
Msg-id | 20130614131535.GC19500@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Patch for fail-back without fresh backup (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch for fail-back without fresh backup
|
Список | pgsql-hackers |
On 2013-06-14 09:08:15 -0400, Tom Lane wrote: > Heikki Linnakangas <hlinnakangas@vmware.com> writes: > > Well, time will tell I guess. The biggest overhead with the checksums is > > exactly the WAL-logging of hint bits. > > Refresh my memory as to why we need to WAL-log hints for checksumming? > I just had my nose in the part of the checksum patch that tediously > copies entire pages out of shared buffers to avoid possible instability > of the hint bits while we checksum and write the page. I am really rather uncomfortable with that piece of code, and I hacked it up after Jeff Janes had reported a bug there (The one aborting WAL replay to early...). So I am very happy that you are looking at it. Jeff Davis and I were talking about whether the usage of PGXAC->delayChkpt makes the whole thing sufficiently safe at pgcon - we couldn't find any real danger but... > Given that we're > paying that cost, I don't see why we'd need to do any extra WAL-logging > (above and beyond the log-when-freeze cost that we have to pay already). > But I've not absorbed any caffeine yet today, so maybe I'm just missing > it. The usual torn page spiel I think. If we crash while only one half of the page made it to disk we would get spurious checksum failures from there on. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: