On Mon, Mar 6, 2017 at 3:57 PM, Andres Freund <and...@anarazel.de> wrote: > I'm ok with not immediately doing so, but I think Peter's design isn't > in line with achieving something like this.
I would be okay with doing this if we had a grab-bag of expensive checks, that all pretty much require some combination of ExclusiveLocks and/or ShareLocks anyway, and are amenable to being combined. I could see that happening, but we're a long way off from that. When it does happen, we might have other things that are a bit like bt_index_parent_check(), in terms of locking requirements and degree of thoroughness, that might themselves require other parameters specific to the verification that they perform that we cannot anticipate. For example, maybe bt_index_parent_check() could have a parameter that is a probability that any given IndexTuple will be verified against its heap tuple. Then you could have something like a PRNG seed argument, so you can check different tuples every day. There are many possibilities, and I hope that eventually amcheck has this kind of very rich functionality. When you use the interface you describe to "stack" several checks at once, less important parameters, like the ones I suggest are going to be an awkward fit, and so will probably be excluded. I'm not opposed to having what amounts to a second interface to what bt_index_check() does, to make this kind of thing work where it makes sense. Really, bt_index_parent_check() is almost an alternative interface to the same functionality today. There can be another one in the future, if it serves a purpose, and the locking requirements are roughly the same for all the checks. I'd be fine with that. Let's just get the basic feature in for now, though. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
