Re: Block-level CRC checks
От | Aidan Van Dyk |
---|---|
Тема | Re: Block-level CRC checks |
Дата | |
Msg-id | 20081002160558.GY16893@yugib.highrise.ca обсуждение исходный текст |
Ответ на | Re: Block-level CRC checks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Block-level CRC checks
|
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [081002 11:40]: > "Jonah H. Harris" <jonah.harris@gmail.com> writes: > > Just to see where to go from here... I want to make sure the options > > I've seen in this thread are laid out clearly: > > > 1. Hold an exclusive lock on the buffer during the call to smgrwrite > > OR > > 2. Doublebuffer the write > > OR > > 3. Do some crufty magic to ignore hint-bit updates > > Right, I think everyone agrees now that #2 seems like the most > preferable option for writing the checksum. However, that still > leaves us lacking a solution for torn pages during a write that > follows a hint bit update. We may end up with some "crufty > magic" anyway for dealing with that. How does your current "write" strategy handle this situation. I mean, how do you currently guarnetee that between when you call write() and the kernel copies the buffer internally, no hint-bit are updated? #define write(fd, buf, count) buffer_crc_write(fd, buf, count) whatever protection you have on the regular write is sufficient. The time of the protection will need to start before the "buffer" period instead of just the write, (and maybe not the write syscall anymore) but with CPU caches and speed, the buffer period should be <= the time of the write() syscall... Your fsync is your "on disk guarentee", not the write, and that won't change. But I thought you didn't really care about hint-bit updates, even in the current strategy... but I'm fully ignorant about the code, sorry... a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: