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: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-11-02T17:56:10Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> 1. in VACUUM or brin_summarize_new_values, we only process fully loaded
> ranges, and ignore the partial range at end of table.

OK.

> 2. when summarization is requested on the partial range at the end of a
> table, we acquire extension lock on the rel, then compute relation size
> and run summarization with the lock held.  This guarantees that we don't
> miss any pages.  This is bad for concurrency though, so it's only done
> in that specific scenario.

Hm, I wonder how this will play with the active proposals around
reimplementing relation extension locks.  All that work seems to be
assuming that the extension lock is only held for a short time and
nothing much beyond physical extension is done while holding it.
I'm afraid that you may be introducing a risk of e.g. deadlocks
if you do this.

If VACUUM and brin_summarize_new_values both ignore the partial
range, then what else would request this?  Can't we just decree
that we don't summarize the partial range, period?

			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