Re: BRIN indexes - TRAP: BadArgument

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Erik Rijkers <er@xs4all.nl>, Emanuel Calvo <3manuek@esdebian.org>, Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Nicolas Barbier <nicolas.barbier@gmail.com>, Claudio Freire <klaussfreire@gmail.com>, Josh Berkus <josh@agliodbs.com>, Andres Freund <andres@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-10-29T20:11:53Z
Lists: pgsql-hackers
Heikki Linnakangas wrote:
> On 10/07/2014 01:33 AM, Alvaro Herrera wrote:

> >I added an USE_ASSERTION-only block in brininsert that runs the union
> >support proc and compares the output with the one from regular addValue.
> >I haven't tested this too much yet.
> 
> Ok, that's better than nothing. I wonder if it's too strict, though. It uses
> brin_tuple_equal(), which does a memcmp() on the tuples. That will trip for
> any non-meaningful differences, like the scale in a numeric.

True.  I'm not real sure how to do better, though.  For types that have
a btree opclass it's easy, because we can just use the btree equality
function to compare the values.  But most interesting cases would not
have btree opclasses; those are covered by the minmax family of
opclasses.

> It would be wise to reserve some more support procedure numbers, for future
> expansion. Currently, support procs 1-4 are used by BRIN itself, and higher
> numbers can be used by the opclass. minmax opclasses uses 5-8 for the <, <=,
> >= and > operators. If we ever want to add a new, optional, support function
> to BRIN, we're out of luck. Let's document that e.g. support procs < 10 are
> reserved for BRIN.

Sure.  I hope we never need to add a seventh optional support function ...

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


Commits

  1. Refactor per-page logic common to all redo routines to a new function.

  2. Reduce use of heavyweight locking inside hash AM.

  3. Scan the buffer pool just once, not once per fork, during relation drop.

  4. Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>