On Mon, Mar 27, 2023 at 2:34 PM Peter Geoghegan <p...@bowt.ie> wrote: > > Since this was back-patched, I think it's probably better to just > > remove the error. We can introduce new validation if we want, but that > > should probably be master-only. > > That makes sense.
Patch attached. > I don't think that it's particularly likely that having refined > aborted speculative insertion amcheck coverage will make a critical > difference to any user, at any time. But "amcheck as documentation of > the on-disk format" is reason enough to have it. Sure, if someone feels like writing the code. I have to admit that I have mixed feelings about this whole direction. In concept, I agree with you entirely: a fringe benefit of having checks that tell us whether or not a page is valid is that it helps to make clear what page states we think are valid. In practice, however, the point you raise in your first sentence weighs awfully heavily with me. Spending a lot of energy on checks that are unlikely to catch practical problems feels like it may not be the best use of time. I'm not sure exactly where to draw the line, but it seems highly likely to be that there are things we could deduce about the page that wouldn't be worth the effort. For example, would we bother checking that a tuple with an in-progress xmin does not have a smaller natts value than a tuple with a committed xmin? Or that natts values are non-decreasing across a HOT chain? I suspect there are even more obscure examples of things that should be true but might not really be worth worrying about in the code. -- Robert Haas EDB: http://www.enterprisedb.com
0001-amcheck-In-verify_heapam-allows-tuples-with-xmin-0.patch
Description: Binary data
