Re: BRIN indexes - TRAP: BadArgument

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: 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-05T20:54:19Z
Lists: pgsql-hackers

Attachments

Jeff Janes wrote:

> At line 252 of brin_xlog.c, should the UnlockReleaseBuffer(metabuf) be
> protected by a BufferIsValid?

Yes, that was just me being careless.  Fixed.

> Now I am getting segfaults during normal (i.e. no intentional crashes)
> operations.  I think I was seeing them sometimes before as well, I just
> wasn't looking for them.

Interesting.  I was neglecting to test for empty index tuples in the
Consistent support function.  Should be fixed now, and I verified that
the other support functions check for this condition (AFAICS this was
the only straggler -- I had fixed all the others already).

> I think this is related to having block ranges which have no tuples in them
> when they are first summarized.  If I take out the "with t as (delete from
> foo returning *) insert into foo select * from t", then I don't see the
> crashes

Exactly.

After fixing that I noticed that there was an assertion (about
collations) failing under certain conditions with your script.  I also
fixed that.  I also added a test for regress.  I didn't have time to
distill a standalone test case for your crash, though.

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