On Thu, Apr 16, 2020 at 03:47:34PM -0700, Jeremy Schneider wrote: > Data checksums are a hard requirement across the entire RDS PostgreSQL > fleet - we do not allow it to be disabled in RDS. I've definitely seen a > lot of hard evidence (for example, customer cases I've personally been > involved in) that it catches problems. Oh, that's good to know. Thanks for the information. I pushed hard as well to make this a requirement on what I work on. > I could not exaggerate how useful > and important I think this feature is: being able to very quickly and > easily know that a problem originated outside of the PostgreSQL code. The worst part with checksums disabled is having to tell a customer or a support staff that you don't actually know from where the problem comes, what is the actual origin of it, and why you think that the error you are seeing in the Postgres logs is most likely linked to a lower-level corruption as there can be many patterns, like broken btree pages, toast errors, missing attributes in catalogs, failures with FK references, primary key duplicates, etc. And people like to complain a lot about the database being broken because that's a very sensitive piece and usually more things depend on it. With checksums enabled, you still cannot say exactly from where the problem comes, but you can redirect the complains more easily to the correct people to help find out what the actual problem is. Even better, you can also know if a problem probably comes directly from Postgres and some backend logic if you don't see a checksum failure (note that could be as well a misdesigned HA workflow, custom backup script as well who knows but at least you know that something you control directly gets wrong). And the error message provided is clear. > This was in part what led to that long blog article I wrote about > checksums, and it's why enabling checksums was happiness hint #1 until I > broke them into categories. Reference? ;p -- Michael
Attachment:
signature.asc
Description: PGP signature
