Re: BRIN indexes - TRAP: BadArgument

Greg Stark <stark@mit.edu>

From: Greg Stark <stark@mit.edu>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Michael Paquier <michael.paquier@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Robert Haas <robertmhaas@gmail.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-11T13:13:45Z
Lists: pgsql-hackers
On Tue, Nov 11, 2014 at 1:04 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
>> It might be clearer ...
>
> Patches welcome :-)

Or perhaps there could still be a single opaque field but have two
optional opclass methods "scaninit" and "rescan" which allow the op
class to set or reset whichever fields inside opaque that need to be
reset.


-- 
greg


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>