On Friday, May 10, 2013 10:24 PM Greg Stark wrote: On Fri, May 10, 2013 at 5:31 PM, Amit Kapila <amit.kap...@huawei.com> wrote: >> In the case where one block is missing, how can it even reach to next record >> to check "prev" pointer. >> I think it can be possible when one of the record is corrupt and following >> are okay which I think is the >> case in which it can proceed with warning as suggested by Simon.
>A single WAL record can be over 24kB. The checksum covers the entire >WAL record and if it reports corruption it can be because a chunk in >the middle wasn't flushed to disk before the system crashed. The >beginning of the WAL record with the length and checksum and the >entire following record with its prev pointer might have been flushed >but the missing block in the middle of this record means it can't be >replayed. This would be a normal situation in case of a system crash. The only point I wanted to say was it can be only "one such record", length can be large or small. >If you replayed the following record but not this record you would >have an inconsistent database. The following record could be an insert >for a child table with a foreign key reference to a tuple that was >inserted by the skipped record for example. Resulting in a database >that is logically inconsistent. The corrupt record can be such that it can lead to inconsistency in database or it could be a commit record of transaction which has performed only select operation. It will be difficult or not possible to find such information during recovery, but informing DBA/user at such occasion can be useful and with an optional way for him to continue (although I am not sure how in such a case DBA can decide, may be need some other information as well). The reason why it can be useful to allow DBA/user intervention in such cases is that, in case of ignoring data after one corrupt record, it can still take time for DBA/user to find which of the operations he needs to perform again. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
