Re: [HACKERS] amcheck (B-Tree integrity checking tool)
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] amcheck (B-Tree integrity checking tool) |
Дата | |
Msg-id | CAH2-Wzkequua--p1mXpS-UkmENM-=n5iFgBzYJo9OnKQhtoGGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] amcheck (B-Tree integrity checking tool) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] amcheck (B-Tree integrity checking tool)
|
Список | pgsql-hackers |
On Mon, Mar 6, 2017 at 3:57 PM, Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: