Horton

Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-10-31T13:59:33Z
Lists: pgsql-hackers 
Michael Paquier <michael.paquier@gmail.com> writes:
> On Tue, Oct 31, 2017 at 4:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, we're still missing an understanding of why we didn't see it
>> before; the inadequate locking was surely there before.

> Because 24992c6d has added a check on the offset number by using
> PageIndexTupleDeleteNoCompact() in brin_doupdate() making checks
> tighter, no?

No, I don't see how it's tighter.  The old code matched supplied
offnum(s) against the indexes of not-unused items, and then after
that loop it complained if they weren't all matched.  So it should
also have failed, albeit with a different error message, if it were
passed an offnum corresponding to a no-longer-live tuple.

			regards, tom lane

Commits

  1. Fix BRIN summarization concurrent with extension

  2. Fix corner-case errors in brin_doupdate().

  3. Rewrite PageIndexDeleteNoCompact into a form that only deletes 1 tuple.

  4. Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use it.

  5. Close some holes in BRIN page assignment