On 10 May 2013 13:39, Greg Stark <st...@mit.edu> wrote: > On Fri, May 10, 2013 at 7:44 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> Having one corrupt record followed by a valid record is not an >>> abnormal situation. It could easily be the correct end of WAL. >> >> I disagree, that *is* an abnormal situation and would not be the >> "correct end-of-WAL". >> >> Each WAL record contains a "prev" pointer to the last WAL record. So >> for the next record to be valid the prev pointer would need to be >> exactly correct. > > Well then you're wrong. The OS makes no guarantee that blocks are > written out in order. When the system crashes any random subset of the > blocks written but not synced might have been written to disk and > others not. There could be megabytes of correct WAL written with just > one block in the middle of the first record not written. If no xlog > sync had occurred (or one was in progress but not completed) then > that's the correct end of WAL.
I agree that the correct end of WAL is where the last sync occurred. We don't write() WAL except with an immediate sync(), so the chances of what you say happening are very low to impossible. The timing window between the write and the sync is negligible and yet I/O would need to occur in that window and also be out of order from the order of the write, which is unlikely because an I/O elevator would either not touch the order of writes at all, or would want to maintain sequential order to avoid head movement, which is what we want. I guess we should add here "...with disks, maybe not with SSDs". In any case, what is more important is that your idea to make an occasional write of the minRecoveryPoint and then use that to cross check against current LSN would allow us to at least confirm that we have a single corrupt record and report that situation accurately to the user. That idea will cover 95+% of such problems anyway, since what we care about is long sequences of WAL records, not just the last few written at crash, which the above discussion focuses on. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
