WIP patch to improve amvalidate functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: WIP patch to improve amvalidate functions
Date: 2016-01-20 22:36:55
Message-ID: 6681.1453329415@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I spent some time trying to improve the amvalidate functions that were
committed in a rather crude state in 65c5fcd353a859da. Attached is a
very-much-WIP patch showing where I'm headed:

* Check operator and function signatures (argument and result types)
not only their strategy numbers.

* Apply more thorough checks for missing operators and support functions.

* Don't throw ERROR if avoidable, because doing it like that means you can
only identify one problem per run. Instead, print messages at INFO level
and make the amvalidate function return false if there are any complaints.
(A credible alternative would be to print the messages as WARNINGs, but
I think INFO is actually the right choice here, since the point of calling
amvalidate is to see those messages.)

* Make the messages more user-friendly by printing object names not just
OIDs.

I went through the amvalidate modules in the order they're shown in the
attached patch, and only the last (brinvalidate) is really fully
developed. I need to go back and bring the others up to snuff, including
getting down to just one copy of the support routines that I wrote.
(I'm thinking of dumping those into a new file access/index/amvalidate.c.)
Also, I think the identify_opfamily_groups() function I wrote for BRIN
will allow improvement of the other modules' cross-checks for missing
operators/functions, but I've not tried yet.

Also, after this is done some of the queries in opr_sanity.sql will be
redundant and removable, but I didn't do that here.

I'm posting this now just in case anyone has some comments, or quibbles
about the overall intent. In particular, if anyone has an idea for a more
thorough missing-objects check on BRIN opfamilies, I would like to hear
it. The fact that there are two kinds of opfamilies with rather different
internal consistency requirements is a real pain there, and the check
rules I have here are definitely the result of some trial and error.

Comments?

regards, tom lane

Attachment Content-Type Size
better-amvalidate-1.patch text/x-diff 64.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-01-20 22:40:20 Re: Releasing in September
Previous Message Bruce Momjian 2016-01-20 22:31:51 Re: No Issue Tracker - Say it Ain't So!