Horton

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

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-10-31T18:10:53Z
Lists: pgsql-hackers 
Tom Lane wrote:

> I really don't understand how any of this "let's release the buffer
> lock and then take it back later" logic is supposed to work reliably.

So summarize_range first inserts the placeholder tuple, which is there
purposefully for other processes to update concurrently; then, without
blocking any other process, scan the page range and update the
placeholder tuple (this could take a long time, so it'd be a bad idea
to hold buffer lock for that long).

I think what we should do is rethink the locking considerations in
brin_doupdate vs. brinGetTupleForHeapBlock, and how they are used in
summarize_range and brininsert.  In summarize_range, instead of hoping
that in some cases we will not need to re-obtain the placeholder tuple,
just do that in all cases keeping the buffer locked until the tuple is
updated.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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