On Thu, Jun 11, 2015 at 2:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Jun 11, 2015 at 08:39:05AM -0400, Bruce Momjian wrote: > On Thu, Jun 11, 2015 at 07:12:36AM +0200, hydra wrote: > > I am entering this discussion a bit late, so maybe I am missing the point. > > But SR is using xlog and there is a crc32 checksum on each xlog record. So > > why would you need to compare the whole thing again when each record has > > been approved during replication ? > > > > > > > > Hello Jan, > > you don't have it if you don't want to. However I'd like to have the > > possibility to do so and thus I was asking - is it possible? Are you guys doing > > it? > > > > The reasons are mentioned above, but still: > > - bugs can appear anywhere, > > - the bug report mentioned before also states to check the data, but does not > > give and hints how to do it, that's why I asked here > > The answer is "no".
You are falling into a trap I see often. There is a flaw in another database product, and you want Postgres to fix it or monitor for it. Postgres just doesn't have that problem to the same level. We have different problems, and we allocate resources to add features based on our own problems, not the problems of other database products.
I didn't bring up this topic because I would have problem with data replication consistency on MySQL. Indeed, I've been using different kinds of replication and after setting it up correctly (which took me some time), I've managed to live 3 years (while doing constant upgrades on the databases) without the data being different. It really helped me to know it's ok and many of the bugs that could have caused the data to differ could be spotted and monitored. Thankfully no data corruption occurred yet (to my best knowledge).
I've posted a real life experience of having a hard time doing a switchover and realizing something was wrong (data missing, old data present, etc.) with PostgreSQL. But it's general, not PostgreSQL specific, because: - every software has bugs, - replication involves software and hardware, both vulnerable to data corruption, - data in the database is one of the most critical parts in IT.
Please don't blindly close your eyes saying this does not affect PostgreSQL. Besides, you are not checking, how can you know?
It's like and old joke: A: "We never had a security incident" B: "Are you monitoring it?" A: "Err.. no."