Horton

Re: BRIN indexes - TRAP: BadArgument

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Greg Stark <stark@mit.edu>
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-11T12:52:34Z
Lists: pgsql-hackers

Attachments

Greg Stark wrote:
> On Tue, Nov 11, 2014 at 12:12 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > As far as I understand, the scan keys don't change within any given
> > scan; if they do, the rescan AM method is called, at which point we
> > should reset whatever is cached about the previous scan.
> 
> But am I guaranteed that rescan will throw away the opcinfo struct and
> its opaque element? I guess that's the heart of the uncertainty I had.

Well, it should, and if not that's a bug, which should be fixed by the
attached (untested) patch.

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