Horton

Re: BRIN indexes - TRAP: BadArgument

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: 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-10T21:15:52Z
Lists: pgsql-hackers 
Alvaro Herrera wrote:

> Hm, I think I see what's happening.  The xl_brin_update record
> references two buffers, one which is target for the updated tuple and
> another which is the revmap buffer.  When the update target buffer is
> being first used we set the INIT bit which removes the buffer reference
> from the xlog record; in that case, if the revmap buffer is first being
> modified after the prior checkpoint, that revmap buffer receives backup
> block number 0; but the code hardcodes it as 1 on the expectation that
> the buffer that's target for the update will receive 0.  The attached
> patch should fix this.

Pushed, thanks for the report.

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