On Wed, Oct 6, 2021 at 1:15 PM Robert Haas <robertmh...@gmail.com> wrote: > > Where I might go further than you or Mark (not sure) is on this: I > > also think that it's the caller's job to not call the functions with > > temp relations, or (in the case of the index verification stuff) with > > !indisready or !indisvalid relations. I believe that these ought to > > also be treated as basic questions about the relation, just like in my > > GIN example. But that's as far as I go here. > > I am on board with this, with slight trepidation.
It may not be a great design, or even a good one. My argument is just that it's the least worst design overall. It is the most consistent with the general design of the system, for reasons that are pretty deeply baked into the system. I'm reminded of the fact that REINDEX CONCURRENTLY's completion became blocked due to similar trepidations. Understandably so. > > I agree that nbtree and heapam verification ought to agree here. But > > my point was just that this behavior just makes sense: what we have is > > something just like an empty relation. > > I am not confident that this behavior is optimal. It's pretty > arbitrary. It's like saying "well, you asked me to check that everyone > in the car was wearing seatbelts, and the car has no seatbelts, so > we're good!" I prefer to think of it as "there is nobody in the car, so we're all good!". > The analogy here is: are we trying to verify that the relations are > valid? Or are we just trying to verify that they are as valid as we > can expect them to be? I think that we do the latter (or something much closer to the latter than to the former). It's actually a very Karl Popper thing. Absence of evidence isn't evidence of absence -- period. We can get into a conversation about degrees of confidence, but that doesn't seem like it'll ever affect how we go about designing these things. A lot of my disagreements around this stuff (especially with Mark) seem to stem from this basic understanding of things, in one way or another. > No, that's existing code from btree_index_mainfork_expected. I thought > you were saying that verify_heapam.c should adopt the same approach, > and I was agreeing, not because I think it's necessarily the perfect > approach, but for consistency. Sorry, I somehow read that code as having an ERROR, not a NOTICE. (Even though I wrote the code myself.) -- Peter Geoghegan
