On 3/11/16 3:31 PM, Peter Geoghegan wrote:
>> Can we come up with names that more clearly identify the difference
>> >between those two functions? I mean,_parent_ does not make it
>> >particularly obvious that the second function acquires exclusive lock
>> >and performs more thorough checks.
> Dunno about that. It's defining characteristic is that it checks child
> pages against their parent IMV. Things are not often defined in terms
> of their locking requirements.
First, thanks for your work on this. I've wanted it in the past.
I agree the name isn't very clear. Perhaps _recurse?
I also agree that the nmodule name isn't very clear. If this is meant to
be the start of a generic consistency checker, lets call it that.
Otherwise, it should be marked as being specific to btrees, because
presumably we might eventually want similar tools for GIN, etc. (FWIW
I'd vote for a general consistency checker).
I know the vacuum race condition would be very rare, but I don't think
it can be ignored. Last thing you want out of a consistency checker is
false negatives/positives. I do think it would be reasonable to just
wholesale block against concurrent vacuums, but I don't think there's
any reasonable way to do that.
I would prefer the ability to do something other than raising an error
when corruption is found, so that you could find all corruption in an
index. Obviously could log to a different level. Another option would be
SRFs that return info about all the corruption found, but that's
probably overkill.
It'd be nice if you had the option to obey vacuum_cost_delay when
running this, but that's clearly just a nice-to-have (or maybe just obey
it all the time, since it defaults to 0).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
