Re: BRIN indexes - TRAP: BadArgument

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Erik Rijkers <er@xs4all.nl>, Emanuel Calvo <3manuek@esdebian.org>, Simon Riggs <simon@2ndquadrant.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-11-08T03:27:14Z
Lists: pgsql-hackers
Tom Lane wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
> > I'm having problems getting this to compile on MSVC. Attached is a patch
> > which fixes the problem.
> 
> The committed code is completely broken on compilers that don't accept
> varargs macros, and this patch will not make them happier.

I tried to make it fire only on GCC, which is known to support variadic
macros, but I evidently failed.

> Probably what needs to happen is to put extra parentheses into the call
> sites, along the lines of
> 
>        #ifdef BRIN_DEBUG
>        #define BRIN_elog(args) elog args
>        #else
>        #define BRIN_elog(args) ((void) 0)
>        #endif
> 
> 
>        BRIN_elog((LOG, "fmt", ...));

That works for me, thanks for the suggestion.

> Or we could decide we don't need this debugging crud anymore and just
> nuke it all.

I'm removing one which seems pointless, but keeping the others for now.
We can always remove them later.  (I also left BRIN_DEBUG turned on by
default; I'm turning it off.)

-- 
Á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>